Re: [gtk-list] Re: Two more Gtk questions (fast frame rates and thread safety)

[Rob Browning <rlb cs utexas edu>]

Owen Taylor <owt1@cornell.edu> writes:

> You can look at the source code for the GIMP, or gsumi
> (http://www.msc.cornell.edu/~otaylor/gsumi/) if you want an example.
> gsumi might be a bit simpler.

OK, I'll poke around.  I assume that a gtk_image is not a normal
XImage (not that anything about an XImage is normal).  Probably some
kind of RGB image.  I'll see if I can figure it out from the code.  It
may be overkill for our purposes since our data is already subsampled
to 3/3/2 when it comes in.  Using a full blown 24bit RGB is excessive,
but if gdk uses XShm (which we don't now) it could conceivably be
faster anyway.

> Sounds like the same thing should work fine. On the other hand, if
> you want to modify the gtk source to be truly thread safe, then
> you'll probably make lots of people quite happy. (It looked a bit
> difficult, though, when I took a look at it.)

Hmm.  That could be pretty tricky depending on how much the authors
have relied on static data and globals, and even if you do get gtk to
DTRT, you still have to make sure all your other X libraries have been
compiled thread safe.  I've been pushing to make sure that we get that
done for the next Debian release, but it's not ready yet.

Overall, for most apps, just making sure no more than one thread's in
the X stuff at a time is probably sufficient, and probably allows the
gtk code to be more efficient with fewer tricks than if everything had
to be reentrant/thread safe.  It certainly requires less head
scratching when writing the code.  I'm not sure what I think about
making gtk really thread safe, on a fine grained level.  I guess the
only way to know what the overhead would be would be to do it and
see...

I could see adding the kind of hacks I mentioned in the previous
message as standard gtk behavior/policy.  Then gtk_main could be
rewritten to respect the internal X mutex so that you don't even have
to use the gtk idle function trick[1], and gtk could also release the
mutex before calling any callbacks, and re-acquire it on return.  This
would make it so that all the user had to do was to remember to
acquire and release the mutex (i.e. gtk_begin_commands,
gtk_end_commands) around any gtk, gdk, or X calls.  Implementing this
wouldn't be all that hard.

[1] Although I think there was some (performance?) reason I switched
to using an work proc from the iteration approach under motif.  I just
can't recall what it was right now.

-- 
Rob