Re: GC graphics_exposures

On Mon, 3 Feb 2003 00:54:09 +0000
Tor Lillqvist <[email protected]> wrote:

> I did some hacking on this, trying various more or less convoluted
> ways of finding out if part of the source rectangle of the blit is
> obscured, and the corresponding part of the destination rectangle thus
> needs a GraphicsExpose-style event.
> 
> The solution below uses the only relatively recently documented
> GetRandomRgn() API. I'm not 100% satisfied, there are certainly race
> possibilities. But it's the best I could come up with. I tried to use
> ScrollWindowEx(), but couldn't figure out what the returned hrgnUpdate
> region really is supposed to indicate, and if it is of any use in
> implementing a GraphicsExpose workalike...
> 
> As you see, there is debugging output still left in the code. Also, it
> might be a good idea not to use InvalidateRgn(), but instead directly
> generate a GDK expose event (which the InvalidateRgn() call eventually
> would cause to be generated anyway).

Yes it works for me. I have to add this to make it compile with msvc 6.0:

#ifndef SYSRGN
int WINAPI GetRandomRgn (HDC,HRGN,INT);
#define SYSRGN  4
#endif (borrowed from mingw's w32api)

Also, it still copies the invalid region before exposing it. This causes a
quick flash/flicker before the exposure is called. Maybe the invalid region
could be removed from the src-region for BitBlt? This could get complicated if
it's not a simple rectangle.

Or, if it's easier, set a clip region to the destination drawable.

-- 
Peter Zelezny.