[[lazarus] Window refresh and painting architecture]

Michal Bukovjan mbukovjan at netscape.net
Fri Mar 3 03:05:22 EST 2000

Sounds reasonable to me. I myself always wondered why so many methods and
messages for this repainting stuff - I bet this could be made more efficient.

But I don't think that only window manager knows about other windows affecting
our window - also sibling windows can.

*Generally*, I would opt for minimal duplicating of work between widgets -
less bloat to say - so for example if GTK widget set handle something, let it
handle something, and do not do the same in our LCL. So if your idea complies
with this case, I would suggest trying your approach out...

Just my opinion.

Michal Bukovjan

"Peter Dyson" <peter at skel.demon.co.uk> wrote:
> I have been studying the message paths and calls made by the
> InvalidateRect Update Paint et al. There seems to be an awful 
> lot of message passing which can be got rid of if we have to 
> encapsulate the windows behaviour.
> For Example
> control calls invalidate 
> invalidate calls API invalidate
> windows updates the invalid rect for that window.
> windows then sends a paint when msg q is empty
> control asks windows for the invalid rects accumulated
> then paints it
> Now if TWinControl handles its own invalid regions
> thats one less msg to spew out, we will still have to 
> get an invalid rect from the window manager as only
> it knows about other windows affecting this one.
> Child controls should get handled in much the same
> way as now, this is only required for the few instances
> where large drawing areas are used.
> Also when the control calls class method update to
> force a refresh, the API call  UpdateWindow is called
> along with windows posting a wm paint message back.
> No gain if you want to force another window but one
> nested API call and one deep msg q in less if the 
> TWinControl can call its own paint method without
> going through all that.
> Can anyone see any disadvantages in TWinControl
> maintaining its own invalid rect and internal painting.
> It would not affect the public interface of the class
> and would encapuslate a part of the WinAPI within
> the class heirachy, which certainly makes it different 
> to Delphi while still compatible.
> Peter   
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>     archives at http://www.miraclec.com/list_archives/lazarus

Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.

More information about the Lazarus mailing list