[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Glitches with the GTK toolkit

From: Jan D.
Subject: Re: Glitches with the GTK toolkit
Date: Fri, 07 Jan 2005 18:32:54 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]