Re: Slow GTK3 redisplay

[chad <yandros@MIT.EDU>]

On 14 Aug 2012, at 06:04, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

>>>>>> On Mon, 13 Aug 2012 20:32:31 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>> FWIW, there's almost no difference on MS-Windows: 54.8 sec vs 54.05,
>> so it's similar to other toolkits except GTK3.
> 
> On the NS port, if some input event such as mouse movement occurs
> while the benchmark is going on, then the scroll bar update gets
> clumsy (first run) or stops completely (second run).  And for the
> second run, C-g becomes unworkable until the benchmark completes.

Huh; I didn't see any problems. (My timings yesterday were 38.7
`normal' and 40.1 `minimal', which didn't seem worth reporting via
email).

When you say `mouse movement', do you mean emacs cursor movement
with the mouse, or scroll bar movement with the mouse, or do you
just mean that the mouse cursor moves while emacs scrolls?

I just repeated the test with a recent checkout, and while I
could not effectively use the mouse to move the scroll bar during
the benchmark, it ran to completion in 36.4 with me attempting to
drag the scrollbar thumb, click in the buffer with the mouse, and
just moving the mouse in random patterns over the window, and
37.0 with me just moving the mouse in random patterns over the
window. This is under macosx 10.8, built `--with-ns''.  

Were you running Emacs -Q?

*Chad