[lazarus] CVS Updates

Andrew Johnson acjgenius at earthlink.net
Fri Oct 3 21:57:36 EDT 2003


On Fri, 2003-10-03 at 21:16, Marc Weustink wrote:
> >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.

hrmm I am not sure. this is really the problem - begin paint can pass a
rect. if we are double buffering we should only create a buffer of the
size of that rect, otherwise we waste memory. potentially quite a lot if
say only a small portion of a large form is invalidated. 

Which means that we would be dealing with a bitmap of smaller size and
0,0 origin, so calls to drawing primitives would need to know what the
actual size of the buffer is and what the rect is, and adjust according
to the top/left origin, i.e the rect passed is (25,25,40,40), so we get
a bitmap of 15x15. so drawing functions would need to subtract 25 from
the top and left. 

If this kind of information can be gotten from the winapi great, but I
don't think it can. you can't get the paintstruct of a dc afaik, so we
need to have a cache of paintstructs, like a fast list of them keyed by
the dc, so we can look up the dc in this cache in a function much like
gtk DCOrigin, and if it finds a paintstruct keyed with that DC it
returns the actual top/left. so drawing functions can addjust if the
rect origin isn't 0,0.

but it would work sorta like 

BeginPaint -> call win32 begin paint, create buffer, create temp things
like actual buffer bitmap, cache passed paintstruct, hwnd, and buffer
and "real" begin paint dc., returns buffer

arc -> getbufferorigin -> look up paintstruct in cache, get offset ->
call win32 function offset to buffer

end paint -> look up cache to get "real" dc, bitblt buffer to real dc,
get all info and delete temp stuff, remove paintstruct from cache,
delete buffer, call win32 EndPaint

am I making any sense?

I haven't done all too much in depth thinking so I could be going  too
complicated. 

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

yeah some of it. most of it isn't ever used anyway.

Andrew






More information about the Lazarus mailing list