GNOME Bugzilla – Bug 594880
Drawing issues in ExoIconView (csw)
Last modified: 2009-09-15 15:44:00 UTC
I'm poking around in the dark here a little bit so please excuse if some of my descriptions are not accurate (and lengthy). Since I've switched to GTK+ with client-side windows, I'm experiencing drawing issues in ExoIconView, the custom icon view implementation we use in Thunar. When the user switches to a previously viewed folder, Thunar scrolls down to the first file that was visible in it. This is done by setting values of a GtkAdjustment, followed by a call to gdk_window_move(window, -xvalue, -yvalue), followed by gdk_window_process_updates(window, TRUE) [1]. While normal scrolling (triggered by the user) seems to be fine, this particular situation causes the view not to be repainted properly. I checked the invalidated region with gdk_window_get_update_area() and found something weird: Without CSW it is: (x = 0, y = 6, width = 333, height = 439) With CSW it is: (x = 0, y = 439, width = 333, height = 6) The result can be seen in a video I'll link to as soon as it has finished uploading. Any ideas so far? [1] http://git.xfce.org/xfce/exo/tree/exo/exo-icon-view.c#n2928 (use of gdk_window_move in ExoIconView)
That looks weird. In this example what was the values of the arguments to gdk_window_move? x=0, y=-6 ?
Yes, here's a tiny bit of debugging output I added to GTK+: gdk_window_move_resize_internal (0x919c000, with_move = 1, x = 0, y = -6, width = -1, height = -1): move native children expose
Here's the video demonstrating the issue. It also shows that with GDK_NATIVE_WINDOWS set, it doesn't happen. Trying to invalidate the entire bin_window used in the icon view helps a little bit but isn't sufficient. http://lunar-linux.org/~jannis/videos/xfce/exo-icon-view-csw-1.ogv
The core problem seems to be that the code in question calls gdk_window_move from inside an expose handler. This will directly modify the window contents for the scroll (i.e. copy the affected area). However, this will then be overdrawn when the expose handler finishes. I'll try to figure out in more detail how this breaks.
(In reply to comment #4) > The core problem seems to be that the code in question calls gdk_window_move > from inside an expose handler. This will directly modify the window contents > for the scroll (i.e. copy the affected area). However, this will then be > overdrawn when the expose handler finishes. I just figured that out too. That's where the automatic scrolling differs from interactive scrolling: it's performed in the expose event handler. > I'll try to figure out in more detail how this breaks. Thanks Alex, I appreciate that. If there's anything I can do to help, please let me know.
Moving the delayed exo_icon_scroll_to_path() call from the expose handler into an idle function solves the issue for me. I wonder... would you still say it's a bug in GTK+/GDK?
I need to think about how this would have worked before csw and how well it can be handled in csw. But its too late today, will look at this next week.
Ok, thanks.
fixed in git master
Thanks, Alex! I just tested the fix and it works fine.