[Lazarus] Finding MacAddress

[SteveG]

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