> Sorry. That is the connection I have not yet made with RB. When you say
> implement my paint event as normal, what is normal? Is the paint event where
> changes to my graphics should take place? If so, what triggers this event?
The Paint event will be invoked by RB whenever your Canvas needs to be
redrawn -- such as when its parent window is first opened, or another window
that was on top of it moves away, or you call Refresh on the canvas -- and
the Graphics object that is the parameter of the Paint event is what your
Canvas should draw into. RB translates your drawing commands into operating
system commands that result in the actual onscreen drawing.
Now, a common misconception with canvases and paint events is that the paint
event is called once, and you respond by doing some drawing, and then RB
saves that picture and uses it whenever the canvas needs to be re-shown.
Then people ask "how do I get the Paint event to fire again so it will show
the picture I drew?" That is not how it works; the Paint event happens on
its own, and it happens each time so much as a single pixel of your window
needs to be redrawn. You just need to implement the Paint event and let the
system worry about when to fire it off.
Putting code into an Event (or Event Handler, as they are now called in
RB2005) is called "implementing" (or "handling") the event. So the normal
implementation of a Paint event is simply to put drawing code into the
Graphics object that was passed in. This is straightforward, but it can
cause flicker for all but the simplest drawings, because the user can see
each individual drawing command take effect on the screen.
AutoBufferingCanvas works by intercepting the Paint event before it gets to
your canvas (subclasses can do this, it's what events are for). It then
creates a new Graphics object for you to draw into, and sends your canvas a
new Paint event that looks just like the old one, except it gives you the
new Graphics object instead of the original. That way, your canvas does all
its drawing to the new Graphics object, which stores the results offscreen,
and then AutoBufferingCanvas transfers the resulting pixels to the original
Graphics object in one operation, so you don't see the individual drawing
commands taking effect.
OS X already does this automatically, so AutoBufferingCanvas is smart enough
not to do all this on OS X, because it would just slow things down. That's
why it's called AutoBufferingCanvas instead of just BufferingCanvas.
Does all that make sense?
lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|