|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |