[[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