Re: Glitches with the GTK toolkit

[Jan D.]

YAMAMOTO Mitsuharu wrote:

> This topic is somewhat old.  But I'd like to take up this because the
> similar problem also occurs in Carbon Emacs, where drawing text is
> much slower than in X11.

In the GTK case, it was the drawing of scroll bars that was slow.  But 
it is a lot faster now, it should be equally fast as for other GTK 
applications.

> How about preventing redisplay from pausing in the case that there are
> no pending inputs other than the mouse movement?  One can "squeeze" a
> sequence of mouse movement events into the latest one, and I think
> it's OK to postpone such kind of events until redisplay is completed.
>
> Here's a patch for testing the above idea.  It would be better to make
> redisplay pause even in the case mentioned above, if the latest mouse
> movement gets too old.

On GTK I actually don't see any difference, but on OSX I do.  It is an 
improvement, and slower machines will probably benefit.  Does this 
affect any other operations that dragging the mode line?

   Jan D.