Re: [gtk-list] Re: X and idles => incredible slowdowns

[Deborah Swayne <dfs research att com>]

> Instead of using an idle function, make your function myidle() a
> timeout with a very short delay (say 30 or 40ms), while increasing
> your step size.

I wasn't following this discussion until today, when I started
implementing real-time point cloud rotation while hoping to
continue having good response on the control panel.

First try: threads

I first tried threads, at the request of a friend of mine on the R
development team who wants to be able to break in on my event loop,
or subsume it under the R loop; I'm not sure.

The rotation looks good, but there's unacceptable delay in the
widget response while rotation is going on.  When I compare it
with the old X implementation of the same code, the difference is
striking -- there's no perceptible delay in the X version.

In the gtk version, the rotation doesn't stop crisply, but makes
a few limping steps even after the check shows up in the checkbox
that turns it off.  (I can't swear I implemented this correctly,
of course, but the behavior was fine except for this delay.)

Second try: gtk_idle_add, then gtk_idle_add_priority

I then tried gtk_idle_add_priority, giving the point cloud
rotation the lowest priority.  The performance is definitely
better than the threaded version -- response to the checkbox is
pretty crisp now.  However, when I try to drag a scrollbar at the
same time, I still get a slow, jerky response.

I'll try Jon's suggestion above; I'm not proud.  But I'm puzzled.
Why should gtk be so much slower than X?

[This behavior obtained both under Redhat 6.1 on a laptop, and on
an X terminal connected to a monster SGI.]

Debby