realbasic-games
[Top] [All Lists]

Re: Canvases sometimes black

To: REALbasic Games <realbasic-games at lists dot realsoftware dot com>
Subject: Re: Canvases sometimes black
From: Lars Jensen <larsjensen at rcn dot com>
Date: Mon, 27 Jun 2005 11:24:48 -0400
Delivered-to: realbasic-games at lists dot realsoftware dot com
> There is no implementation of the paint event for either the canvas or
> its containing window.

So if you obscure part of the canvas with the control window, then drag the
control window away, revealing the canvas again, what happens? Do you get
your image or a chunk of blank space?

If so, that's by luck. You should put UpdateGameScreen into your Paint
event, but UpdateGameScreen shouldn't reference your Canvas directly
(otherwise no buffering will occur); it should draw to the Graphics object
that is passed to the Paint event.

That's more flexible anyway -- then UpdateGameScreen (perhaps better named
PaintGameScreen) can be used to draw to any Graphics object, such as one
that is part of a printer or Picture.

> Certain events occur within the control window which dictate that the
> canvas window's content must be updated.

The "classic" way for the control window to force a redraw of the canvas is
for it to call canvas.Refresh. However, that erases the canvas first on some
systems, causing flicker. That's what AutoBufferingCanvas.PaintBuffered is
for; it cause a Paint event to fire, but without erasing the canvas first.
This works as long as your Paint event completely redraws the entire visible
rectangle, so that no pixels from the previous image are left. (I just draw
the entire image and worry about optimization later if needed.)

In the absence of PaintBuffered, the control window could do just as it is
doing now: call a routine that draws directly to the canvas. (This is
usually implemented as a routine that simply passes MyCanvas.Graphics to
another routine that draws to any Graphics object, as described above.)
PaintBuffered is just a convenience so you don't have to create such a
routine yourself -- it already exists to support AutoBufferingCanvas, so I
just made it public.

> What is it about "returning true" if seen about a lot
> of things regarding painting?

Some events specify a boolean return value to indicate whether the event
should be processed further -- in those cases, returning True means that
your event handler has taken care of everything and the superclass shouldn't
do anything more with the event. This is typical for things like MouseDown
and KeyDown, but it doesn't apply to the Paint event, which has no return
value.

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>

<Prev in Thread] Current Thread [Next in Thread>