DrawReversible

[Peder Y]

Hi!
My application contains a simple drawing module. The user can draw
lines, ellipses and so on. Now, I'm a fan of visual feedback. The user
should see the changes he or she does at the very instant they have been
done. For example, the user draws an ellipse. The ellipse need to be
moved a tad to the left, so the user grabs it with the mouse and moves
it in place. Most professional applications solve this by drawing a
reversible outline of the object(s) selected as they are moved, and then
redraw them in full when the mouse releases them. However, no
DrawReversibleEllipse or DrawReversiblePath are included in the API. how
can this be achieved?

Thanks!

- Peder -

[Bob Powell [MVP]]

You could draw to a GraphicsPath, flatten the path to create a set of points
then do DrawReversibleLine calls for each line segment in the PathPonts
array.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Peder Y" <[e-mail]> wrote in message
news:e$**************@TK2MSFTNGP15.phx.gbl...

Hi!
My application contains a simple drawing module. The user can draw
lines, ellipses and so on. Now, I'm a fan of visual feedback. The user
should see the changes he or she does at the very instant they have been
done. For example, the user draws an ellipse. The ellipse need to be
moved a tad to the left, so the user grabs it with the mouse and moves
it in place. Most professional applications solve this by drawing a
reversible outline of the object(s) selected as they are moved, and then
redraw them in full when the mouse releases them. However, no
DrawReversibleEllipse or DrawReversiblePath are included in the API. how
can this be achieved?

Thanks!

- Peder -

[Ian Griffiths [C# MVP]]

Actualy most professional applications don't work this way any more. (Not
the good ones, anyway.)

This 'reversible' drawing simply uses XOR to draw the features, and there
are lots of good reasons not to do this. The only reason this technique
became popular is because it is fairly efficient, and back in the early
1990s, it was the only way of drawing things fast enough to be interactive
and usable. But graphics cards these days are fast enough that this isn't
necessary any more, and you can get much better results using other
techniques. I wrote this a while ago describing some of the techniques:

http://www.interact-sw.co.uk/graphic...ideredharmful/

If you want an example of the kinds of things that go wrong when you use
XOR, I also wrote about that...

http://www.interact-sw.co.uk/iangblo...9/xorartifacts

Hope that helps.
--
Ian Griffiths - http://www.interact-sw.co.uk/iangblog/
DevelopMentor - http://www.develop.com/

"Peder Y" <[e-mail]> wrote:

My application contains a simple drawing module. The user can draw lines,
ellipses and so on. Now, I'm a fan of visual feedback. The user should see
the changes he or she does at the very instant they have been done. For
example, the user draws an ellipse. The ellipse need to be moved a tad to
the left, so the user grabs it with the mouse and moves it in place. Most
professional applications solve this by drawing a reversible outline of
the object(s) selected as they are moved, and then redraw them in full
when the mouse releases them. However, no DrawReversibleEllipse or
DrawReversiblePath are included in the API. how can this be achieved?

[Peder Y]

Hi Ian and thanks for nice pointers!
I have read all your articles and find them very useful. However, I must
admit I approached this another way at first. My original attempt was to
move the graphics primitives themselves and invalidate the area(s) in
question. Now, try painting a 1024x768 image at the bottommost z-order
on a panel, then move the primitives that are placed on top. Maybe I was
going about this the wrong way, but I get a lot of flicker. I'd love to
solve this with transparent objects, but GDI+ seems to produce flicker
no matter. I totally agree with your xor standpoints, but resolved to it
as a last (-intermediate:) solution. Surely someone must have written an
article on this somtime?

- Peder -
Ian Griffiths [C# MVP] wrote:

Actualy most professional applications don't work this way any more. (Not
the good ones, anyway.)

This 'reversible' drawing simply uses XOR to draw the features, and there
are lots of good reasons not to do this. The only reason this technique
became popular is because it is fairly efficient, and back in the early
1990s, it was the only way of drawing things fast enough to be interactive
and usable. But graphics cards these days are fast enough that this isn't
necessary any more, and you can get much better results using other
techniques. I wrote this a while ago describing some of the techniques:

http://www.interact-sw.co.uk/graphic...ideredharmful/

If you want an example of the kinds of things that go wrong when you use
XOR, I also wrote about that...

http://www.interact-sw.co.uk/iangblo...9/xorartifacts

Hope that helps.

[Ian Griffiths [C# MVP]]

Flicker occurs when the contents of the screen alternate rapidly between two
or more different sets of contents.

This occurs naturally when you redraw stuff on the screen if you're drawing
anything more than a single primitive. For example, if you draw a grey
background, and then you draw a black ellipse on top of that, there will be
a point in time where you've drawn the grey bit but not the black bit.
Sometimes what you see on screen will therefore just be the grey background,
and sometimes it will be the black ellipse on top of the grey background.

So if you repeatedly update the screen, it'll alternate rapidly between grey
and black, and this is what causes flicker. (Invalidating a screen area
causes it to be redrawn from scratch.)

There are two ways around this:

(1) Draw everything so fast that you don't get to see the intermediate
state.

(2) Do all your drawing off-screen into a bitmap, and then copy that onto
the screen when you're done.

Both of these work by making sure that the screen never contains
partially-drawn results. (1) is pretty hard to achieve on Windows, mainly
because it's very hard to know how long you've got before your results will
next be refreshed to the monitor. So (2) is the usual approach.

Windows Forms has built-in support for (2). Just set the DoubleBuffer and
AllPaintingInWmPaint styles on your control, and it arranges for all
repainting to go via an off-screen bitmap, eliminating flicker.
--
Ian Griffiths - http://www.interact-sw.co.uk/iangblog/
DevelopMentor - http://www.develop.com/

"Peder Y" wrote:

Hi Ian and thanks for nice pointers!
I have read all your articles and find them very useful. However, I must
admit I approached this another way at first. My original attempt was to
move the graphics primitives themselves and invalidate the area(s) in
question. Now, try painting a 1024x768 image at the bottommost z-order on
a panel, then move the primitives that are placed on top. Maybe I was
going about this the wrong way, but I get a lot of flicker. I'd love to
solve this with transparent objects, but GDI+ seems to produce flicker no
matter. I totally agree with your xor standpoints, but resolved to it as a
last (-intermediate:) solution. Surely someone must have written an
article on this somtime?