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 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.
So, for good drawing performance, we should only draw into the visible
porting of the view.
However, Lazarus doesn't use the kEventParamRgnHandle parameter and
consequently the application
can't do the optimization.
I suggest to add the region to the TCarbonContext class.
The next question is how this region, or at least its bounding box,
should be known to the
application. We have, for example, a GetClipRect method attached to
various objects.
The painting emulator should handle the region, split it into
rectangles, and call the paint handlers for every rectangle. The
ClipRect has to be initialized for every rectangle, and it should be
applied to all coordinates in the LCL/RTL painting methods, before
calling the widgetset specific drawing primitives.
This behaviour may have been implemented in the widgetsets already (dunno)?
A further question is how to invalidate part of a user interface object,
e.g. a TPanel. A good
example is scrolling, were we only want to redraw that part of the
object that really needs it. If
the optimization is impossible using controls/HiViews, than maybe a
TPanel shouldn't be a
control/HiView ?
Windows has a function for scrolling screen contents without sending
WM_PAINT requests. Only those parts of the client area have to be
repainted, which have been scrolled into view.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
