After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 561591 - Redraw problems on Openmoko since r18802 due to gdk_window_freeze_toplevel_updates
Redraw problems on Openmoko since r18802 due to gdk_window_freeze_toplevel_up...
Product: gtk+
Classification: Platform
Component: Widget: Other
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2008-11-19 21:17 UTC by Tom White
Modified: 2016-06-06 02:08 UTC
See Also:
GNOME target: ---
GNOME version: ---

Nasty workaround by neutralising toplevel freeze (1.18 KB, patch)
2008-11-19 21:18 UTC, Tom White
none Details | Review
Patch used to monitor internals (3.41 KB, patch)
2008-11-19 21:19 UTC, Tom White
none Details | Review
Log file from TangoGPS with monitored GTK+ (22.29 KB, text/plain)
2008-11-19 21:21 UTC, Tom White

Description Tom White 2008-11-19 21:17:29 UTC
After the current Openmoko distribution was updated from GTK 2.10.14 to 2.12.11, redraw stopped working for many GTK programs as described in the following Openmoko bug report:

I checked that the problem went away with a revert of the GTK package alone, and then tried some versions in between.  This isolated the appearance of the problem to somewhere between versions 2.11.6 and 2.12.0.  Then I bisected the SVN revisions in between these two and tracked the regression down to revision 18802 of GTK, which introduced the gdk_window_freeze_toplevel_updates_libgtk_only() mechanism.

I confirmed that the problem concerns this mechanism by removing the checks for gdk_window_is_toplevel_frozen() in gdk_window_schedule_update(), gdk_window_process_all_updates() and gdk_window_process_updates().  I've attached my patch to do this, but obviously it's a very nasty workaround and I don't fully understand the implications of it.

I dug a little deeper by adding some watchpoints to the code (patch to do this also attached).  The offending toplevel freeze occurs in gtk_window_move_resize() in gtk/gtkwindow.c.  Just before it happens, window->configure_request_count is incremented, so I monitored that value as well.

It appears that configure_request_count is incremented and the updates frozen in the expectation that gtk_window_configure_event() would later be called, where it would be unfrozen.  However, when the window is initially created, the subsequent gtk_window_configure_event() never occurs and so the window remains frozen.  If the window is subsequently switched away from and then back to (I guess causing an extra configure event), then the unfreeze happens and things are back to normal.  Some configure events do occur on startup before the freeze - perhaps there is a timing issue here?

I've attached a log of the output from TangoGPS when using my "monitored" version of GTK.  The "** cb_gps_timer()" lines are about a second apart in time, and the "update_and_descendants_freeze_count = 1" line appears while the problem is apparent.  The change to "update_and_descendants_freeze_count = 0" occurs when the main window of TangoGPS is switched away from then back to, and the problem is not apparent after that.

The window manager used in Openmoko for my testing is Enlightenment with the Illume module for mobile applications.

Is anyone more knowledgable able to comment?
Comment 1 Tom White 2008-11-19 21:18:39 UTC
Created attachment 123070 [details] [review]
Nasty workaround by neutralising toplevel freeze
Comment 2 Tom White 2008-11-19 21:19:38 UTC
Created attachment 123071 [details] [review]
Patch used to monitor internals
Comment 3 Tom White 2008-11-19 21:21:20 UTC
Created attachment 123072 [details]
Log file from TangoGPS with monitored GTK+
Comment 4 Matthias Clasen 2008-11-26 04:41:01 UTC
The freeze_toplevel logic was introduced for bug 426246
Comment 5 Tom White 2008-12-09 00:46:34 UTC
Comment from Raster (developer of Enlightenment) about this:

"e definitely does things differently to other wm's - it has a state machine
that it leaves to settle and then evaluates it on idle - and THEN sends fake
events and configures windows etc. as such under ICCCM this is something the wm
is free to do - not every configure request from an app will necessarily be

For the time being it's been worked around by patching Enlightenment to send extra events to the clients.  For a "real" fix, the logic added to fix #426246 needs to be altered to not assume that every configure request will be matched by a move-resize event.
Comment 6 Matthias Clasen 2016-06-06 02:08:41 UTC
we've recently fixed a longstanding bug in the freeze logic; it might help for this