GNOME Bugzilla – Bug 537859
Problem with large windows on Win32
Last modified: 2009-11-04 09:43:25 UTC
Please describe the problem: The scrolled window is not updated anymore (demo case see below) Steps to reproduce: To run the demo: * un-tar the attachement * place xapp.exe into a standard glib/gtk environment * start xapp.exe from window's console * click the 'start' button Actual results: What happens: * The app creates a window with a start button and a scrolled window which itself contains a list (tree view). * When the start button is pressed a thread is started which in turn calls g_idle_add() 3000 times. * The idle function adds a row to the list and tries to scroll the scrolled window. * Exactly after 1560 times the scrolled window stops to scroll (nothing is displayed anymore) while on the console the counter keeps on counting to the end. Expected results: Does this happen every time? Yes Other information: Some notes: * I've compiled and run the app on linux: no problems. * I've tried on windows 2000 and xp, with recent and older glib/gtk versions: same strange behaviour. * You can click on the 'start' button again after 3000 cycles and the scrolled window will not restart. * When the cycles are done, moving the scroll bar up and down may help to show all lines; however, please do not consider this to be a solution... In the real environment I have got really strange results with the whole scrolled widgets->window not updated at all anymore (no scrollbar) etc. * Why a thread is used: In the real environment I use a whole layer of threads/idle-functions around gtk for all widgets with good results for a longer time, only the scrolled window widget seems to have problems. And, without a thread the list would not be updated at all since the button would stay pressed in, and so there was no idle time at all. * Waiting with g_usleep(100000) before each call to g_idle_add() does not help. * To best view the sources, set tabstop to 4 spaces
Created attachment 112577 [details] source code and demo xapp.exe for win32
Just attaching sample source code (as a single source file) would be enough. Anybody who wants to debug this will be able to recompile it fine anyway.
The code uses GTK+ from separate threads. That doesn't work on Windows. *** This bug has been marked as a duplicate of 60620 ***
Ah, sorry. I spoke too soon, you don't call GTK+ from multiple threads after all.
Around 1560 lines the height of the window for the widget to which you add the lines becomes larger than 32767. That means that the very complex "big window emulation" code in gdk kicks in. Apparently there are sill bugs in that code. As such the limit of 32767, and much of the big window emulation code, comes from the X11 backend. In X11 there really is a hard 16-bit limit for window dimensions. On Windows, the limit is much higher (and in fact not documented as far as I can recall), but still lower than the 32-bit dimensions that GDK wants to offer. So some big window emulation is needed in any case if we really want to be able to handle GDK's full 32-bit dimensions. I guess it could be argued that the limit before the emulation code kicks in could be increased some orders of magnitude on Win32, especially if/as there are bugs in the code...
However, simply changing the instances of 65536 to 1000000 and 32767 to 499999 in gdkgeometry-win32.c didn't help. Maybe I remember wrong, and there really are 16-bit limits for window sizes and/or coordinates in Win32, too.
Just FYI: * To verify what Tor said I've created a new sample code which deletes the first row when more than 30 rows are added to the list; so the scrolled window is not expanded too much: no problems on win32 (and linux) then. * The first sample code (see above) had a small bug not related the issue here: After the main gtk window is closed, g_free(_nGThread) is probably wrong (glib warning: doubly freed mem; on win32 visible only when using gdb, or, on linux, even without gdb sometimes).
Created attachment 112596 [details] sample showing no problems if # of rows kept <1560
Now in GTK+ 2.18 with client side windows this problem is no longer present.