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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]