GNOME Bugzilla – Bug 153567
Repaint glitches in widgets
Last modified: 2008-07-21 12:46:56 UTC
Please describe the problem: GTK widgets occasionally fail to repaint correctly after dragging another window over the top of the GTK window, thus leaving one or more pixel rows or columns of unpainted vertical or horizontal lines on the widget. Minimizing and restoring GTK window, or covering it and uncovering it again, thus sending another repaint request will usually fix the problem. Steps to reproduce: The problem is random and not consistantly reproducable, but it does seem to occur with all GTK applications on Windows. I have been able to reproduce the problem using the GTK applications from the GTK tutorial, as well as using GIMP for Windows. The problem seems to occur most often when a window is dragged slowly over the GTK window, thus causing rapid repainting of relatively small invalid regions. Actual results: Occasionally, parts of widgets are left with blank lines where repainting has not been done. Expected results: Widgets should repaint correctly. Does this happen every time? No. The problem is random and cannot be consistantly reproduced. Other information: Operating system is Windows XP. Video card is Matrox Millenium G400 with latest display drivers from Matrox.
Does this still happen to you? I noticed this in older versions of GTK, but I have not seen it occur in quite awhile now.
This may have been fixed in #310522. Can you confirm if this is happening with the last 2.10 GTK release (which includes that patch)? http://bugzilla.gnome.org/show_bug.cgi?id=310522
*** Bug 427663 has been marked as a duplicate of this bug. ***
I'm still seeing this with GTK+ 2.12.10 on Windows XP.
Yeah, I've confirmed it as well. I tried looking into it, but so far I have no idea what is causing it. It does not seem to happen on Vista, because the drawing model works differently there. But it's definitely still a bug in GTK.
Created attachment 114274 [details] [review] Redraw window from timer A little hacky, but it seems to fix it for me. To really observe that it's fixing the problem, change the timeout value from 200 to something more noticeable.. set to 4000 or something. Drag a window around until you can really reproduce the bug, and then wait for the timeout to catch up.
So the idea here is that I don't know how to figure out what area needs to be invalidated, so I just want to redraw the entire window when we're dragging other windows over ours (which we can tell when we get WM_SYNCPAINT). But obviously doing it on every WM_SYNCPAINT would be slow and stupid, so we set a timer for some interval (I picked 200, but maybe another works better, I didn't experiment with this too much). If we receive another WM_SYNCPAINT before the timer expires, we reset it. But once the timer expires THEN we redraw the whole window.
I haven't tested your patch but it sounds reasonable. The question of why we don't see this with any regular win32 apps is mostly academic I guess.
Yeah, it kind of bothers me that I don't really know what's causing the problem. Whilst searching around for stuff related to WM_SYNCPAINT I discovered the following link: http://www.codeguru.com/forum/showthread.php?t=283638 This guy demonstrates that he's having the same, or very similar, issue with his apps and he wrote a simple test case. I don't really know enough to be able to say if he's doing anything wrong in his test program or anything. That's a little reassuring, I guess, except that other things like Firefox don't demonstrate this problem and from quickly grepping through the Firefox code I didn't see that they're doing anything with WM_SYNCPAINT. But whatever.
2008-07-21 Cody Russell <bratsche@gnome.org> Bug 153567 – Repaint glitches in widgets * gdk/win32/gdkevents-win32.c: Set a sync timer when we receive WM_SYNCPAINT, and RedrawWindow() once the timer expires.