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

["Timothy M. Shead" <tshead k-3d com>]

As an additional suggestion:

Using a timeout function only works well if you can guarantee that your
drawing time is less than the duration between timeout events.  If not, GTK+
doesn't get a chance to handle events generated by the user (such as your
checkbox).  I've had good success with setting a timeout event to twice the
desired refresh frequency, and only refreshing the display every other
timeout - this way, you guarantee a small amount of idle time for GTK+ to
handle user interaction.

FWIW, I've used this trick for years, starting with straight Win32
programming, on through MFC and, more recently, GTK+ running under both X
and Win32.  Not sure why straight X would be so much more responsive ...
client/server design vs. event loops?

Tim Shead

----- Original Message -----
From: "Deborah Swayne" <dfs@research.att.com>
To: <gtk-list@redhat.com>
Sent: Wednesday, May 03, 2000 5:31 PM
Subject: [gtk-list] Re: X and idles => incredible slowdowns


> > 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
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
/dev/null
>
>