Re: gtk1.2 -> gtk2.0: recursing expose events

[Owen Taylor <otaylor redhat com>]

On Sun, 2003-05-25 at 13:35, Richard Guenther wrote:
> Hi!
>
> I'm trying to get GLAME ported to gtk/gnome 2.0 and am stuck at trying
> to find out, why gtk segfaults on me if recursing into the expose event
> of a GtkDrawingArea.
>
> The matter is to do async redrawing by checking gtk_events_pending() in
> a heavyweight redraw function which is connected to the expose_event of
> a drawing area.
>
> The code looks like
>
> expose_event_cb()
> {
>    static int expose_cnt;
>
>    if (expose_cnt++ > 0) {
>        /* merge exposes */
>        return TRUE;
>    }
>
> again:
>    expose_cnt = 0;
>
>    for (;;) {
>
>        /* partial redraw */
>
>       if (gtk_events_pending()) {
>            while (gtk_events_pending())
>                gtk_main_iteration();
>
>          if (expose_cnt > 0) {
>             /* remember undrawn */
>               goto out;
>            }
>       }
>
>    }
>
> out:
>    if (expose_cnt > 0)
>        goto again;
>
>    return TRUE;
> }
>
> And I'm getting backtraces like
>
> #5  <signal handler called>
> #6  0x0f057370 in gdk_event_get_graphics_expose () from
> /usr/lib/libgdk-x11-2.0.so.0
> #7  0x0f058f30 in gdk_add_client_message_filter () from
> /usr/lib/libgdk-x11-2.0.so.0
> #8  0x0f0591d0 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0
> #9  0x0f059474 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0
> #10 0x0ede7990 in g_get_current_time () from /usr/lib/libglib-2.0.so.0
> #11 0x0ede8c78 in g_main_context_dispatch () from
> /usr/lib/libglib-2.0.so.0
> #12 0x0ede9000 in g_main_context_dispatch () from
> /usr/lib/libglib-2.0.so.0
> #13 0x0ede9264 in g_main_context_iteration () from
> /usr/lib/libglib-2.0.so.0
> #14 0x0f1a063c in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0
>
> where frame #14 is the gtk_main_iteration() call in the above loop.
>
> Any hints what changed between gtk1.2 and 2.0 to make this fail? Any ideas
> on how to convert such handlers?

I'd actually be *very* interested if you could produce a test case
that reliably reproduces the above crash ... it's the same backtrace as:

 http://bugzilla.gnome.org/show_bug.cgi?id=105745

A bad GDK crash that something in GNOME is triggering in rare 
conditions that we've had no luck in tracking down so far.

And the goal is that no matter how weird stuff an app does, GTK+
shouldn't crash.

(In fact, I'm so interested, that I won't make my usual fuss
about small, standalone test cases. Whatever code you have
is fine.)

Though, in the end, I'm somewhat surprised that code of that
nature worked in GTK+-1.2. Both GTK+-1.2 and GTK+-2.0 already have
expose compression code internally before the app ever gets
an expose. The GTK+-1.2 code looks a bit like the above (but 
hunts the event queue instead of iterating the main loop), the
GTK+-2.0 code is more sophisticated and sane.

So, for your app, just ditch the compression code. When you 
get an expose event, compression has already happened

 event->area is the bounding box
 event->region is the exact GdkRegion of the exposed area

Regards,
                                          Owen