GNOME Bugzilla – Bug 139086
Gtk+ Win32 resizing windows does not redraw contents of window until resize is finished
Last modified: 2004-12-22 21:47:04 UTC
Any Gtk+ window in win32 does not update correctly while resizing the window, if windows has set show window contents while draging a window.
Can't reproduce, at least not with testgtk. But my working copies of GTK+ and GLib HEAD have some changes, related to trying to fix bug #137968 and related stuff in GTK+.
i'd call this a feature bug in that any window that you resize that is a gtk+ window does not update until the resize is complete. This has been in gtk+ since 1.2. 1. move mouse cursor to the edge of a window until cursor changes to resize grip. 2. click and hold. 3. move mouse and observe that the window contents do not resize as you drag. 4. when you release the window is resized correctly. the bug in these four steps is in three. while dragging the gtk+ window does not update until the drag is complete. I've noticed in 2.4 that it updates faster then in 2.2 but *most* windows apps update as you drag with no noticable jumps. Certainly, gtk+ apps refresh correctly while resizing in X.
(Is this bug a duplicate of bug #135453?) What do you mean by "I've noticed in 2.4 that it updates faster than in 2.2"? Does it update during the resize or not? If you have tried 2.4.x, I assume you build GTK+ yourself? (Yes, I know this is normal on Unix, but it is not so common on Windows.) Have you tried the 2004-01-24 build of GTK+ 2.2.4 from www.gimp.org/win32/downloads.html? On the other hand, the same change is in GTK+ 2.4.x.
(Is this bug a duplicate of bug #135453?) yes What do you mean by "I've noticed in 2.4 that it updates faster than in 2.2"? Does it update during the resize or not? I mean that it doesn't update smoothly during a resize and that from the best that i can recall from 2.2 it seems to update faster in 2.4 (perhaps this means the fix was not in the older version of 2.2 i was using from dropline.net). So, what i'm saying is that the update is not smoothing updating. However, after looking at some other windows applications the performance has improved but still lacking behind. If you have tried 2.4.x, I assume you build GTK+ yourself? (Yes, I know this is normal on Unix, but it is not so common on Windows.) yes i have i just got it built a couple of days ago :) Have you tried the 2004-01-24 build of GTK+ 2.2.4 from www.gimp.org/win32/downloads.html? On the other hand, the same change is in GTK+ 2.4.x. if that was provided in the recent dropline.net release then yes. I'd like to help tweak the source to improve the refresh rate during a build, perhaps thats all i need to understand.
So are you saying that in GTK+ 2.4.0, window updates during a resize do happen (they do for me...), but aren't smooth enough? The way window updates during resizes are handled currently is a bit ad-hoc and hackish, and if fact causes some other problems (see bug #99540, bug #137968, and comment 17 in bug #132113.) I am really not satisfied with it.
another thing i'm noticing that may be related to this bug is that when adjusting an hpan the child panels if they contain buttons themed with the pixbuf theme engine the artwork flickers as if it is not being double buffered. This maybe what is really causing the effect of things not looking smooth. Also, the hpanel handle can be left behind in treeview's and textview's. You can definately see this in the gtk-demo when looking at the textview demo.
As the original reporter himself said this is a duplicate, resolving as such. *** This bug has been marked as a duplicate of 135453 ***