[Top][All Lists]

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

Re: Slow GTK3 redisplay

From: YAMAMOTO Mitsuharu
Subject: Re: Slow GTK3 redisplay
Date: Wed, 15 Aug 2012 08:55:02 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Tue, 14 Aug 2012 09:17:22 -0700, chad <address@hidden> said:

> On 14 Aug 2012, at 06:04, YAMAMOTO Mitsuharu
> <address@hidden> wrote:

>>>>>>> On Mon, 13 Aug 2012 20:32:31 +0300, Eli Zaretskii
>>>>>>> <address@hidden> 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).

Yes, I thought the "semi-hang" problem was more important.  For me,
the second run gives 24 (Default GUI) vs. 16 (Minimal GUI) on the NS
port, and 13 vs. 11 on the Mac port.

> 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?

Just the mouse pointer movement over the Emacs frame.  No click or
drag.  Other input events such as focus switching and keyboard input
like C-p show the same behavior for me.  Of course I tried with -Q.
Also, I could reproduce it on OS X 10.8 with a precompiled binary
downloaded from http://emacsformacosx.com/ .

                                     YAMAMOTO Mitsuharu

reply via email to

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