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

[Richard Guenther <rguenth tat physik uni-tuebingen de>]

On 28 May 2003, Owen Taylor wrote:

> On Wed, 2003-05-28 at 03:52, Richard Guenther wrote:
>
> > 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?

I have that - but f.i. for a zoom out operation on a large waveform I need
to go over a lot of data thats possibly still on disk.

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

They consider it less broken, as they can "abort" a zoom out / zoom in
by zooming in again - with the code in question, the first expose event
doesnt get finished, but instead directly the second one is started
(if its going over the same region, of course).

It works like a charm with gtk+-1.2.

Richard.

> Regards,
>                                                  Owen