GNOME Bugzilla – Bug 310522
Buttons flicker and redraw slowly
Last modified: 2007-06-10 18:22:02 UTC
Please describe the problem: On windows, be it Windows 2000, XP, 2003 Server and so on, GTK Buttons flicker. They blink and redraw slowly, when they are in TreeView headers or just are in windows. Fast computers do not help. Steps to reproduce: 1. Windows UI must be set up to show window contents while dragging. 1.1 Right click on Desktop 1.2 Choose Properties -> Appearance -> Effects 1.3 Make sure "Show window contents while dragging" is checked 1.4 Press OK button 2. Open Gtk-Demo application 3. Choose Button Boxes example 4. Drag the window by it's edges Actual results: Buttons flicker and redraw very slowly, with blinking and overlapping with surrounding boxess. Expected results: Buttons must be redrawn as fast as labels are. Does this happen every time? Yes. Other information: 1. I use GTK build from gladewin32.sourceforge.net 2. This also can be reproduced when buttons are in headers of resizeable columns of TreeView (by resizing these columns) 3. Probably, it happens because someone forgot to write two commands in gtkbutton.c (to create a cliping region and to free it) 4. I'd like to help and to fix it myself, but it seems there is no way for ordinary human to compile GTK in MinGW on Windows :(
Do you still perceive this problem with buttons in particular the newest GTK+ 2.8.x? Is it restricted to just buttons? (Personally I find that *both* buttons and labels (and most other GTK stuff) flicker somewhat while dragging a window around (without changing its size). Don't know why, surely this should not happen.)
The flickering is due to the background being painted during WM_ERASEBKGND processing and then the content being painted by gtk. There's enough of a time gap that the flickering is perceptible. This is discussed in bug #144269.
Now I use gtk-win32-devel-2.8.6-rc3 assembled by Ivan Wong from gladewin32.sourceforge.net The problem still exists and the described behavior hasn't changed. Flickering of separate buttons, which happens only on rare resizing of a window is not that scary. What made the problem unacceptable for me is flickering of TreeView column labels, which are buttons, when resizing a column. This flickering is frequent and very noticeable. For separate buttons, column header buttons and labels together, you can handle the following test: In GTK Demo application, select "Editable Cells" demo under "TreeView" group. A window will appear with "Shpooing list" label on top, TreeView in the middle and two buttons at the bottom. Now take the right edge of the window and __slowly__ pull it right (or left). When I do this, "Shpooing list" label doesn't flicker, "Add item" and "Remove item" buttons at the bottom flicker, and also the rightmost TreeView column header "Yummy" is resized and flickers. When buttons flicker, one can notice that blank rectangle is put to the screen, and then a button is drawn instead of it.
I am not sure whether this relates to this bug, but if you won't drag the right edge of the window very slowly, you may achieve the effect when the window is continously resized, but it's contents remain unresized. Window in this state can remain for a long time, depending on the speed you drag it's border in the same direction.
It looks to me like it's drawing the area twice. If you look in gdkevents-win32.c where it handles WM_ERASEBKGND, remove the erase_background() call and that seems to fix the problem. I'm not sure if this is the correct fix though, because there are obviously many widgets that do not have this problem with flickering. I'm not sure why this is happening with buttons in particular.
I looked into this some more, and I'm pretty certain that my solution is the correct one. Windows is sending us the WM_ERASEBKGND message because hbrBackground is set to NULL. We want to keep it that way, otherwise Windows will not send us this message and it will just happily clear the window background on its own using that brush, which will also cause flicker. We want to receive WM_ERASEBKGND, -not- draw anything, and then return 1 (which we're already doing by setting *ret_valp = 1).
I've been using a modified build of gtk 2.6.x for years that basically does this and have not had problems with it. This and improved drawing performance are among the changes we did that greatly reduce the number of "the app is unusable because it's not a native app" messages we get. FWIW, on win32 I take the messages that the app isn't native to mean that the app doesn't work well / look good because very few people know exactly what native is. The most important drawing performance changes were minimizing GDI object manipulation and optimizing the bitblt from the backing pixmap to the window. These changes were to 2.6 so will probably need to be done differently now that cairo is involved.
Would you mind sending me a copy of your patches? I'd like to take a look at it and see if I can recycle any of it for use in GTK 2.10. I've been trying to get involved in Win32-related hackery in GTK recently.
Created attachment 80908 [details] [review] Proposed patch Sorry, I never actually posted a real patch before.. so here it is.
I just committed this to trunk and gtk-2-10, closing now.
Oops, nevermind I can't close this one. :)