Slow GTK3 redisplay

Slow GTK3 redisplay

[Dmitry Antipov]

Some time ago I did the following simple redisplay benchmark:

(defun scroll-benchmark ()
   (interactive)
   (let ((oldgc gcs-done)
         (oldtime (float-time)))
     (condition-case nil (while t (scroll-up) (redisplay))
       (error (message "GCs: %d Elapsed time: %f seconds"
                       (- gcs-done oldgc) (- (float-time) oldtime))))))

And here are some results of running the code above over xdisp.c,
with different X toolkits and without it. Of course, emacs -Q was used.
GTK3 is 3.2.4, GTK2 is 2.24.8, OpenMotif is 2.3.3, Xaw3d 1.5E, Xaw 1.0.8.

Default GUI means menu bar, tool bar and scroll bar enabled. Minimal GUI
means all of the above is disabled, i.e. the frame state after

(progn (menu-bar-mode 0) (tool-bar-mode 0) (scroll-bar-mode -1)).

Numbers are in seconds.

           Default GUI Minimal GUI
GTK3:        108          34
GTK2:         41          34
OpenMotif:    36          34
Lucid:        38          34
None:         36          33

Here GTK3 GUI is _painfully_ slow. Can someone explain this? Is something
wrong with my GTK3 setup? Am I running heavyweight theme, or what?

Dmitry

Re: Slow GTK3 redisplay

[Tassilo Horn]

Dmitry Antipov <dmantipov@yandex.ru> writes:

Hi Dmitry,

> Numbers are in seconds.
>
>           Default GUI Minimal GUI
> GTK3:        108          34
>
> Here GTK3 GUI is _painfully_ slow. Can someone explain this? Is
> something wrong with my GTK3 setup? Am I running heavyweight theme, or
> what?

I can reproduce the issue with GTK3:

Menu Bar | Tool Bar | Time (1st run) | Time (2nd run)
---------+----------+----------------+---------------
yes      | yes      | 187 secs       | 116 secs
yes      | no       | 90 secs        | 8 secs
no       | yes      | 204 secs       | 124 secs
no       | no       | 89 secs        | 8 secs

It seems that the presence of a tool-bar slows down scrolling
significantly.  Especially, scrolling for the second time is always fast
unless there's a tool-bar.

Bye,
Tassilo

Re: Slow GTK3 redisplay

[Eli Zaretskii]

> Date: Mon, 13 Aug 2012 16:41:14 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> 
> Some time ago I did the following simple redisplay benchmark:
> 
> (defun scroll-benchmark ()
>    (interactive)
>    (let ((oldgc gcs-done)
>          (oldtime (float-time)))
>      (condition-case nil (while t (scroll-up) (redisplay))
>        (error (message "GCs: %d Elapsed time: %f seconds"
>                        (- gcs-done oldgc) (- (float-time) oldtime))))))
> 
> And here are some results of running the code above over xdisp.c,
> with different X toolkits and without it. Of course, emacs -Q was used.
> GTK3 is 3.2.4, GTK2 is 2.24.8, OpenMotif is 2.3.3, Xaw3d 1.5E, Xaw 1.0.8.
> 
> Default GUI means menu bar, tool bar and scroll bar enabled. Minimal GUI
> means all of the above is disabled, i.e. the frame state after
> 
> (progn (menu-bar-mode 0) (tool-bar-mode 0) (scroll-bar-mode -1)).
> 
> Numbers are in seconds.
> 
>            Default GUI Minimal GUI
> GTK3:        108          34
> GTK2:         41          34
> OpenMotif:    36          34
> Lucid:        38          34
> None:         36          33
> 
> Here GTK3 GUI is _painfully_ slow. Can someone explain this? Is something
> wrong with my GTK3 setup? Am I running heavyweight theme, or what?

FWIW, there's almost no difference on MS-Windows: 54.8 sec vs 54.05,
so it's similar to other toolkits except GTK3.

Sounds like purely a GTK3 problem (IOW, not interesting as far as
Emacs internals go).

Btw, I hope you know that your benchmark is exceedingly unrealistic,
compared with 90% of redisplay operations in real life.  It can be
used for comparison with itself, but it is not indicative of the
display speed in any way, AFAIU.

Re: Slow GTK3 redisplay

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Mon, 13 Aug 2012 15:59:36 +0200
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> It seems that the presence of a tool-bar slows down scrolling
> significantly.

Not "toolbar", but "GTK3 toolbar".

> Especially, scrolling for the second time is always fast

Because the entire buffer is already fontified the second time, so
redisplay has much less work to do.

Re: Slow GTK3 redisplay

[Jan Djärv]

Hello.

2012-08-13 14:41, Dmitry Antipov skrev:
> (defun scroll-benchmark ()
>    (interactive)
>    (let ((oldgc gcs-done)
>          (oldtime (float-time)))
>      (condition-case nil (while t (scroll-up) (redisplay))
>        (error (message "GCs: %d Elapsed time: %f seconds"
>                        (- gcs-done oldgc) (- (float-time) oldtime))))))

This is very syntetic.  But I made a speed up, please try again.
The problem is that the display engine is not made for external tool bars, so 
we (before the fix) redraw tool bars for Gtk+ on just about every redisplay.

Not a big real world problem, or there would have been complaints.

	Jan D.

Re: Slow GTK3 redisplay

[Tassilo Horn]

Jan Djärv <jan.h.d@swipnet.se> writes:

Hi Jan,

> 2012-08-13 14:41, Dmitry Antipov skrev:
>> (defun scroll-benchmark ()
>>    (interactive)
>>    (let ((oldgc gcs-done)
>>          (oldtime (float-time)))
>>      (condition-case nil (while t (scroll-up) (redisplay))
>>        (error (message "GCs: %d Elapsed time: %f seconds"
>>                        (- gcs-done oldgc) (- (float-time) oldtime))))))
>
> This is very syntetic.  But I made a speed up, please try again.  The
> problem is that the display engine is not made for external tool bars,
> so we (before the fix) redraw tool bars for Gtk+ on just about every
> redisplay.

Before your change scrolling once with GTK3 toolbar took 187 seconds,
the second scroll took 116 seconds.  Now, after your change I'm at 94
seconds for the first and 14 seconds for the second run.  That's about
as good as without GTK toolbar.

Bye,
Tassilo

Re: Slow GTK3 redisplay

[YAMAMOTO Mitsuharu]

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

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Slow GTK3 redisplay

[chad]

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

Re: Slow GTK3 redisplay

[YAMAMOTO Mitsuharu]

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