Re: Gdk/Gtk Win32 patch

[Hans Breuer <hans breuer org>]

At 14:03 01.05.00 -0400, Owen Taylor wrote:
>
>Hans Breuer <hans@breuer.org> writes:
> ...
>> * 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.

Do you mean a patch against Changes-1.4.txt ? Why not simply
copy your respective ChangeLog entry ?
The patch for the source is already available (see previous mail).

>
>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.
>
Or use the above for Changes-1.4.txt?

>> 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. 
>
Do I really need to define, what I mean with Race Condition?
Ok: a bug caused by actual execution speed of different parallel 
running parts of software. The bug has mainly to do with timing 
conditions, e.g. everything works fine, if first A() and then B() is
executed, but bad things happen if B() starts while A() isn't finished.
The same may come true in an event based environment, if the code
does require a specific order of events, but the windowing system
sends them with a different order.
On Win32 Gdk see gdk_window_new and handling of WM_CREATE message for
an example.
It is observable not only by switching the compiler to 
"no optimizations"  (== Debug Build), but also by using the better
optimizing Intel comiler instead of MSVC.


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

Maybe, but what if the window invalidation and redrawing is disturbed
by double buffer switching ?

>> 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.)
>
Nice hint! This solves the menu drawing problem. Do you
have any tip in common for check boxes?

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

Fine. My patch does this already.

>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:
>
> [...]
Ok, than someone needs to compare scrolling facilities ...
May GtkLayout already needs proper handling of offsets or do
I need to investigate other things to make it work again?

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

IHMO I'm investigating race conditions; see above.
Concerning my question in regard to design documentation, does
your answer simply mean: No. ?

>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.
>)
>
Sounds like a lot work to be done ... 

>Hope this helps,
>                                        Owen
>
Yep. Thanks,
	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert