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

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-05-28 at 03:52, Richard Guenther wrote:

> > > 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.

[...]
> > 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.)
>
> If you really want to, you can get the glame CVS from sourceforge
> (sf.net/projects/glame)
> and look into src/gui/libgtkwaveform/gtkwaveview.c - the relevant
> functions are gtk_wave_view_redraw_wave and on_area_expose_event (the
> former gets called by the latter), re-enable the #if0'ed code at line
> 650 and you get crashes scrolling the wavewidget very fast.

I'll see if I can get it built... seems a little rough around
the edges perhaps :-)

> Maybe I have time at the weekend to produce a smaller testcase, just
> ripping off all but the above functions and stick the expose to a
> drawing area should be enough, I think.
>
> I just wanted to know if its ok in principle to call gtk_main_iteration()
> from an expose event? And then possibly receive another expose during this
> operation?

A priori, I'd expect it to work fine. The GDK expose generation code
was written with some attention to reentrancy.

That doesn't mean I think it's a good idea...

> > 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
>
> I know, the above code is not expose event compression, but async
> redrawing - redrawing one pixel may cost us >1s here and such we
> check for pending events and execute the main loop just like anyone
> does for busy computation loops. Of course we need to detect other
> expose events coming by and merge them in.

Can I suggest that if expose events are that expensive, you really
should keep a pixmap around with th econtents  visible portion of the
widget?

Then expose events are really fast and when the contents change, you
can simple use a low priority idle to recompute and re-fill-in the
missing portions of the backing pixmap.

If expose events take seconds, users will consider your app broken,
if you have fancy code to abort expose handling and start over.

Regards, 
                                                 Owen