GNOME Bugzilla – Bug 56866
parent_relative background pixmaps handled incorrectly
Last modified: 2011-02-04 16:11:52 UTC
In Win32, the widget background pixmap is positioned incorrectly if it is parent_relative. It should be positioned relative to the origin of the nearest widget in the parent chain that does not have a parent_relative background; instead, it is positioned at the origin of the current widget. The effect of this is that instead of a background image tiling smoothly over a dropdown menu list (for example), the tiling "restarts" with every entry in the list. Looks pretty bad, generates very visible patterns and background interference. I'm going to attach a contextual diff for gdk/win32/gdkevents-win32.c which should fix the problem. It's a small change. When climbing the chain of parents, the code will now accumulate the total offset to the position of the widget in question, and then use that offset information when doing the BitBlt of the background pixmap. N.B. The existing code has an optimization where it uses a brush-fill rather than a blit if the pixmap is very tiny. Since I didn't have a good idea about how to adjust that for parent_relative images, I disabled that optimization if the image is parent_relative. Please give this a once-over; it's trivial code but I have not made changes to this codebase before, so there may be some issue that I don't know about. tml has given it a quick look and says he it is looks OK. If you agree, then in his words: "this patch should be applied to the gtk-1-3- win32-production branch, and some similar one to HEAD".
Created attachment 695 [details] [review] diffs for gdk/win32/gdkevents-win32.c
Fixed in CVS for gtk-1-3-win32-production branch. HEAD fix coming.
In the gtk-1-3-win32-production branch (GTK+ 1.3.0) I could see a clear improvement in testgtk after applying the patch. (I added a few lines to testgtkrc to use background pixmaps in the menu test, and there was clear improvement.) However, in HEAD GTK+ a similar patch didn't work as well. At first, the menu looks good, no "stuttering" in the background pixmap. But when moving the mouse over the menu, after the cursor leaves each menu item, that area is repainted with the top of the background pixmap instead of the properly offset part of the pixmap. Would the reporter have a minimal but complete test case that could help in tracking down the issue? Also, if such a test case is submitted, please could somebody make sure that it indeed works correctly on Unix/X11, so that I don't waste time in trying to find a bug in the Win32 backend if it is fact is cross-platform.
Hmm, sorry, I don't have a simple test case. I've been using this fix with gdk 1.3 and the applications GtkRadiant and GIMP, under Windows, with the EmacsDefSoultriped theme (from gtk.themes.org). Haven't noticed any problems.
Moving open Win32 2.0.0 bugs to 2.0.1 milestone
Putting win32 bugs on 2.2.0 milestone, since we don't plan on having win32 official for the 2.0.x branch.
I think this has been fixed in gtk-2-0 and HEAD. Please try out the build of 2.0.9 that I'll probably upload in some days. Reopen if still buggy.