Re: Gdk/Gtk Win32 patch

[Owen Taylor <otaylor redhat com>]

Hans Breuer <hans@breuer.org> writes:

> Due to recent changes in Gdk (Thu Feb 24 18:11:46 2000  Owen Taylor) 
> the Win32 part in CVS was slightly broken. 

Thanks for working on this. I think Tor has been busy with other
things. 
 
> This patch addresses the following issues:
> 
> make it compile again:
> * adding some headers and define new required functions like
>   _gdk_windowing_window_queue_antiexpose, rename some other
>   like  gdk_window_clear_area -> _gdk_windowing_window_clear_area
> * extend and change region specific functions, as required by
>   Owen's changes. BTW: these are incompatible changes, which
>   break some existing code (e.g. Dia). Shouldn't this comment go 
>   into Changes-1.4.txt?

Yes, it should be. A patch to add that would be appreciated.

I think it can be pretty simple, something like:

 - The boolean operations on GdkRegion have been changed to modify
   the first argument rather than returning a newly allocated
   region.

> * do appropriate makefile changes (MSVC only)
> 
> make it run again (mostly):
> * added GDK_NOTEs here and there to better understand why and where
>   the crashes occure. This was especially usefull because the
>   Win32 port does not run as MSVC5 Debug Built since a while - possibly
>   due to mysterious race conditions while creating windows.
> * finally testgtk was working again - except GtkLayout - but all
>   menues are drawn in black, IHMO because of wrong paint order
>   related to backing store (Just another race condition?)

I'm a bit puzzled when you say "race conditions". I can't imagine
that it is a actually a race condition. 

What I think you mean is that something is drawing on the front buffer
when it is supposed to be drawing on the backing buffer, and then
the backing buffer gets copied over it.

> Unresolved Issues and some Questions:
> --------------------------------------
> On Linux and Win32:
> - testrgb's final stripes aren't visible (on Linux and Win32), 
>   because they are flushed with black. 
>   Is this a feature - or a bug ?

Bug in testrgb. (Well, on Linux, they are properly flushed with gray -
black sounds like a different bug -
 
 win32/gdkwindow-win32.c/gdk_window_set_background() 

needs to save the background color for later use - see the
corresponding x11 function.)

The easy way to fix this will be to wait until we have "don't double
buffer this widget" flag since testrgb is hacky and can't handle
exposes at all.
 
> - I wasn't able to find enough documentation to understand
>   what _gdk_windowing_window_get_offsets is expected to do.
>   Could someone give me an explanation, or even better put
>   it into the sources?

The "offsets" here in X11 come from code to emulate a 32-bit
coordinate space with 16 bit coordinates - the offsets are
between the 

So, the simplest thing to do here is to just return 0,0.
But at some point, Windows will probably need 32-bit emulation
code of its own. (Done rather differently - you don't
need all the fancy scrolling stuff in gdkgeometry-x11.c since
Windows has a straightforward "scroll window" call.) My 
understanding at this point is:

 - Windows95/98 have a 16 bit coordinate space though 
   the Win32 API's take 32 bit coordinates.

 - Windows NT has a 28 bit coordinate space (internally
   coordinates are 32/4 fixed point), but some graphics
   drivers might not handle this properly.

However, this is just vague, secondhand information, and
I think some tests are probably needed to figure out exactly 
what the situation is.

28 bit coordinates would be good enough - but only 16
bit coordinates are present on some Win32 platforms emulation
code is needed.

> - Is there general design documentation (e.g.: Signal Handling,
>   Backing Store) available and/or list of known possible race 
>   conditions, which could help to resolve the remaining 
>   issues?

Again, I don't think you actually mean race conditions. Just
things which aren't drawing on the right buffer. 

So, the thing you simply have to do is to check that all
drawing that is supposed to be on the windowing is going
through the drawing functions in gdkwindow.c.

(For instance, when you draw a line on window - 

 gdk_window_draw_lines() 

 intercepts this and 

 a) translates the coordinates of the drawing call, and 
    coordinates stored in the GC.
    
 b) Redirects the drawing call to the back buffer if necessary.
)

Hope this helps,
                                        Owen