Created attachment 38563 [details] [review]
proposed patch

Created attachment 38569 [details]
a simple and ugly test

There is a test case in testgtk. Doesn't it 'pass'?

Thanks! Looking briefly at the patch, looks good. At least there are lots of
more "minus" lines in the patch than "plus" lines, that's certainly a good sign
in this case ;-)

The test case in testgtk is hard to understand. I have been working on this
issue a little myself, too, and also considered writing a simpler test case ;-)

BTW, even though your patch preserves the X11-style limitation of window
coordinates to 16 bits, and thus presumably is supposed to work on Win9x, your
test program doesn't work correctly on Win98... Do you have any idea what might
be the problem? 

If not, do you think it would be possible to simplify this even further by not
using the SIZE_LIMIT and all and just use full 32-bit window sizes/coordinates?
(That's the approach I had been working on a little.) (Thus ignoring Win9x, but
big windows haven't worked before either, so this wouldn't be a regression.)

Anyway, I am going to commit your change. Would this be an appropriate ChangeLog
entry:

2005-03-12  Ivan, Wong Yat Cheung  <email@ivanwong.info>

	Big window fix for Win32. Big windows now work on NT-based
	Windows. (#169989)

	* gdk/win32/gdkgc-win32.c (_gdk_win32_gdkregion_to_hrgn): Use
	32-bit coordinates.

	* gdk/win32/gdkgeometry-win32.c: Largely rewrite.

	* gdk/win32/gdkwindow-win32.c: Minor related changes.
	

#3, it doesn't work. I will continue to fix any problem. But at least for 
practical case, like the ugly test above and Gnumeric, work quite well.

#5, I will get a win9x box and look into it.

#6, certainly.

Created attachment 38588 [details] [review]
revised

Hans, the test case in testgtk just passed :)

Tor, I suspect that we still create incorrect clip region with Win9X, will
continue to investigate it.

Committed the new patch, thanks.

Is this fixed ?

> #10
Not really. Win9x still doesn't work and I haven't got a box to debug yet.

Ivan, may I suggest VMware... The VMware Workstation 5 beta (time-limited) is
available for free.

Tor, I am very impressed by vmware5. IIRC version 4 on windows is very slow. I
am now playing with vmware5 on sid and it runs as fast as a real desktop. wow.

What I want to say is that win9x is really *funny*. I found that the limit is
not only the size of a window width, but also the screen coordinates of it. i.e.
it's perfectly ok to have [x=0 h=0 w=32767 h=32767]. However, if we create a
child window with [x=10 h=10 w=32767 h=32767], this window will have client area
= [0,0] as in this case right/bottom (both 32777) > 32767. Note that only
CreateWindowEx has this problem. If we later move the [x=0 h=0 w=32767 h=32767]
window to somewhere likes [100,100], the window still have valid client area and
cliping region.

Changing the LIMIT from 32767 to 16000 looks a reasonable solution, as we still
don't have huge screen in this age. I still see some glitches in gnumeric/win32
on win9x though, will continue to look into the problem.

Now with support for Win9x being actively removed from HEAD GTK+, it would be a good time to remove the now mostly pointless 16-bit coordinate limiting code, and just pass the 32-bit GDK coordinates as such to 32-bit GDI. Or am I missing something? I will try to hack on this.

IIRC, win nt actually has 24-bit coordinate limits. But that may be big
enough to ignore the difference from the 32-bit coordinates of GTK+...
24-bits should be enough for, say, a 800,000 row spreadsheet.

Certainly it would be better to have well-working 24-bit coordinates
than 32-bit emulation that has some bugs. (I don't really know the
current state of GTK+/win32 in this area.)

As such the current code does indeed seem to work fine, so there is no immediate need to change it. It's just its complexity that horrifies me, I have absolutely no understanding how it works ;) If it could be replaced by presumably much simpler code, that would be a plus. But on the other hand, if there are apps that really require the full 32-bit GDK coordinates, we don't want to break them by reducing the limit.

The article http://groups.google.co.uk/group/comp.os.ms-windows.programmer.win32/msg/067a84c35053590d says NT-based Windows uses 28.4 fixed point coordinates internally. Hmm, 28 bits is temptingly large... but still not 32 bits.

Testing indicates that although it is possible to create a huge child window (say, 80000 x 80000, which of course is actually not *that* huge) on XP, as soon as you move the child window, it gets resized down to 32767x32767. Unbelievable, isn't it? Also the position of the window gets clamped to (-32768,32767). Of course, nothing like this is documented in MSDN.

It's the WM_WINDOWPOSCHANGING message sent to the window procedure that suggests these clamped coordinates and sizes. If you change them in gdb to what you want them to be before returning from the window procedure (the fields in question are 32-bit ints), Windows believes you, and the window stays its original size and moves to the position you wanted. GDK should always know what size and location child windows have, right, so this approach could be used.

Anyway, I think it's not worth it to go down this path, the risk of breaking something anyway is too large. Better to keep the current code. Resolving as FIXED...

Created attachment 71939 [details] [review]
Patch that makes gdk/win32 pass GDK coordinates as such to GDI

With this patch, the "simple and ugly" test program above works nicely. But there might be problems in more complex cases, so I won't apply this.