[lazarus] CVS Updates

[Marc Weustink]

At 03:04 4-10-2003, Andrew Johnson wrote:
>On Fri, 2003-10-03 at 20:39, Marc Weustink wrote:
> >
> > Hmm.. indeed. First, where do we want doublebuffering to be handled. 
> Should
> > it be part of the interface or should it be part of the LCL.
> >
>
>its a tricky question, because GTK2 automatically does doublebuffering,
>which means sometimes we have to manage it and do it ourselves. So on
>that note I would say defintely use or at least initiate it in the
>interface if at all possible.
>
> > When is it used ? Only while in the LM_PAINT message ?
>
>well it should be whenever it can be. No matter how its done in VCL :D
>
>In the VCL it is only handled in the paint message yes. In GTK2 its
>almost always used by default but because of the having to handle it
>ourselves for custom widgets then likely as far as its concerned it will
>also only be in the Paint message, however it is done from
>beginpaint/endpaint so anywhere that uses those functions will
>automatically get it in GTK2.
>
>So I suppose one way would be to make each interface BeginPaint always
>return a  DoubleBuffer DC, and EndPaint bitblt it to the real one,

Exactly my thoughts. Thats why I asked where it was needed.


>much like I am essentially doing for gtk2 by calling its own native begin and
>end paint methods. This would allow it to be done anywhere those
>functions are called, and since they should be being used by the LCL
>whenever a paint message doesn't pass its own DC that might allow us to
>do this. It would of course mean not actually using the native win32
>BeginPaint/EndPaint(or not returning handling things the same way), and
>would require caching and keeping track of the extra info somehow, and
>thus in all the win32 functions have offset functions to move to
>relative position if a buffered dc(aka in the cache). Maybe this is too
>complicated though...

?? I don't get the complete picture yet, but I do understand that if 
DoubleBuffering is moved to the interface, the win32 interface has to do 
the buffer itself, so it can't pass the native beginpaint.

This all means that the existing buffercode in the LCL should be (re)moved.

Marc