[lazarus] Window refresh and painting architecture

[Marc Weustink]

+ From: Peter Dyson [mailto:peter at skel.demon.co.uk]

+ 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.
+
[snip]

+ 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.

Hmm... you may win one message.... I don't think it's worth it.
You now have to handle regions at two places.

+ 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.

Hmm.... have thought about how the InvalidateRect API call should be handled
this way? (The api doesn't know LCL)

+ 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 you explain

+ 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.

I say OK as long as you have a way to handle the API functions:
  InvalidateRect
  InvalidateRgn
  UpdateWindow
  ValidateRect
  ValidateRgn

But I cant see how you would manage this platform (and if possible LCL)
independent, so I have my doubts.
I think you'll end up with lot of the same work.

Marc