[Lazarus] Optimizing Lazarus drawing performance

Mattias Gaertner nc-gaertnma at netcologne.de
Wed Sep 9 18:12:01 CEST 2009


On Wed, 09 Sep 2009 04:33:42 +0200
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> Adriaan van Os schrieb:
> 
> > "In addition, whether you use QuickDraw or Quartz, the
> > kEventControlDraw event also contains a
> > kEventParamRgnHandle parameter. This region defines the visible
> > portion of the view, and in most
> > cases you should restrict your drawing to this area; any part of
> > the view outside this area is
> > presumably covered by another view and will be overwritten. The
> > HIView compositor determines the
> > size of this region."
> 
> Windows creates separate WM_PAINT messages for all rectangles in the 
> update region, and initializes the GDI clipping rectangle
> accordingly. This removes the need for region checks from the
> painting routines, at some performance penalties: the same component
> can be asked to paint itself multiple times, until all rectangles
> have been painted, so that the initialization of the Canvas and
> fetching data occurs multiple times. At least can a painting routine
> test the ClipRect, to prevent useless painting calls into clipped
> areas.

The clipping area is a region, not a rectangle. Of course often it is a
rectangle.
The question is, if the carbon interface handles all clipping and
region functions correctly.

 
> The Mac approach obviously leaves the clipping to the painting
> routines, and the drawing primitives seem not to handle any clipping
> themselves. If this analysis is correct, and if we want to use the
> same WM_PAINT handlers (consider custom controls!) also on a Mac, an
> emulation of the Windows procedure seems to be required.

Since we are talking about speed: Avoid "emulation" and talk about
mapping.

 
>[...]


Mattias




More information about the Lazarus mailing list