Re: Slow GTK3 redisplay

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Tue, 14 Aug 2012 09:17:22 -0700, chad <yandros@MIT.EDU> said:

> 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).

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
				mituharu@math.s.chiba-u.ac.jp