GNU bug report logs - #28695
26.0.60; Rendering lag spikes caused by double-buffering on Linux

Previous Next

Package: emacs;

Reported by: Bryan Gilbert <bryan <at> bryan.sh>

Date: Wed, 4 Oct 2017 06:20:02 UTC

Severity: normal

Tags: moreinfo

Found in version 26.0.60

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28695 in the body.
You can then email your comments to 28695 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Wed, 04 Oct 2017 06:20:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bryan Gilbert <bryan <at> bryan.sh>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 04 Oct 2017 06:20:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bryan Gilbert <bryan <at> bryan.sh>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
Date: Tue, 03 Oct 2017 23:10:16 -0400
Hi,

I've been using the Emacs 26 release branch and I've noticed a
significant amount of rendering lag spikes. When this occurs the UI
completely locks up in Emacs (and the desktop) for short periods of
time. Better than an explanation I have two very short screencasts
included below the display the behavior.

I've been able to reproduce the problem with 100% reliability using the
`counsel-rg` command from ivy/swiper (full details to reproduce below).
I've also used git bisect to narrow down the exact commit these lag
spikes were introduced as this commit:

https://github.com/emacs-mirror/emacs/commit/c29071587c64efb30792bd72248d3c791abd9337

I was able to verify that reverting to the previous commit before
double-buffering was added completely removed the problem. I've made two
short screencasts, one before the double-buffer commit and the other
after.

Before: http://drop.bryan.sh/YtUzfcSRp7.mp4
After: http://drop.bryan.sh/UyRpSc4NyQ.mp4

The behavior is unaffected by the glxgears program I have running in
both screencasts, I just used it as a method to show when the screen is
locking up. In the second screencast when it looks like the screen is
completely locked up, I am just pressing the 'e' and 'backspace' in
alternation once every second.

Two minor precursors to running the steps to reproduce are that one
would need to be running Linux and have 'rg' installed. 

Steps to Reproduce using emacs -Q:

1. Add the melpa archive

    (require 'package)
    (add-to-list 'package-archives
                '("melpa" . "http://melpa.org/packages/"))

2. Install Counsel:

    (package-refresh-contents)
    (package-install) ;; counsel

3. Enable Ivy:

    (ivy-mode 1)

4. Change counsel-rg minimum query length from 3 characters to 1 character:

    (defun ivy-counsel-ag-function (string base-cmd extra-ag-args)
      (when (null extra-ag-args)
          (setq extra-ag-args ""))
      (if (< (length string) 1)  ;; #1
          (counsel-more-chars 1)
          (let ((default-directory counsel--git-dir)
              (regex (counsel-unquote-regex-parens
                      (setq ivy--old-re
                              (ivy--regex
                              (counsel-unquote-regex-parens string)))))) ;; #2
          (let* ((args-end (string-match " -- " extra-ag-args))
                  (file (if args-end
                          (substring-no-properties extra-ag-args (+ args-end 3))
                          ""))
                  (extra-ag-args (if args-end
                                      (substring-no-properties extra-ag-args 0 args-end)
                                  extra-ag-args))
                  (ag-cmd (format base-cmd
                                  (concat extra-ag-args
                                          " -- "
                                          (shell-quote-argument regex)
                                          file))))
              (if (file-remote-p default-directory)
                  (split-string (shell-command-to-string ag-cmd) "\n" t)
              (counsel--async-command ag-cmd)
              nil)))))

    (advice-add #'counsel-ag-function :override #'+ivy*counsel-ag-function)

5. Run 'counsel-rg', begin typing, and notice large lag spikes

    (counsel-rg)


Step number 3 is a bit of a messy step, however by lowering the minimum
query size from 3 characters to 1 character makes the rendering lag spikes
painfully obvious.

Thanks!


=========================================================================


In GNU Emacs 26.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
 of 2017-09-28 built on borealis
Repository revision: 88a0dd71f10ffb63fba08c062e948551c3e876c2
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description:	Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-xft --with-modules --with-x-toolkit=gtk3
 --without-gconf --without-gsettings --without-gpm --without-m17n-flt
 --with-xwidgets --without-compress-install 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt'
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS NOTIFY ACL GNUTLS
LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES
XWIDGETS LIBSYSTEMD LCMS2

Important settings:
  value of $LC_COLLATE: 
  value of $LC_CTYPE: 
  value of $LC_MESSAGES: 
  value of $LC_MONETARY: 
  value of $LC_NUMERIC: 
  value of $LC_TIME: 
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Wed, 04 Oct 2017 07:54:01 GMT) Full text and rfc822 format available.

Message #8 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bryan Gilbert <bryan <at> bryan.sh>
Cc: 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on Linux
Date: Wed, 04 Oct 2017 10:53:23 +0300
> From: Bryan Gilbert <bryan <at> bryan.sh>
> Date: Tue, 03 Oct 2017 23:10:16 -0400
> 
> Step number 3 is a bit of a messy step, however by lowering the minimum
> query size from 3 characters to 1 character makes the rendering lag spikes
> painfully obvious.

Thanks for the report.

While we are waiting for the double-buffering issues to be looked at,
you should be able to work around this problem by using the following
snippet from NEWS:

  If your system has [the XDBE] extension, but an
  Emacs built with double buffering misbehaves on some displays you use,
  you can disable the feature by adding

    '(inhibit-double-buffering . t)

  to default-frame-alist.  Or inject this parameter into the selected
  frame by evaluating this form:

    (modify-frame-parameters nil '((inhibit-double-buffering . t)))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Wed, 04 Oct 2017 09:06:02 GMT) Full text and rfc822 format available.

Message #11 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bryan Gilbert <bryan <at> bryan.sh>, 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on Linux
Date: Wed, 04 Oct 2017 11:04:49 +0200
> I was able to verify that reverting to the previous commit before
> double-buffering was added completely removed the problem. I've made two
> short screencasts, one before the double-buffer commit and the other
> after.

Unless this problem (and that of Bug#28652) get fixed, we should either
disable double buffering by default or add some special warning so users
do not have to spend their time investigating this issue.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Wed, 04 Oct 2017 09:33:02 GMT) Full text and rfc822 format available.

Message #14 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: bryan <at> bryan.sh, 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on Linux
Date: Wed, 04 Oct 2017 12:32:01 +0300
> Date: Wed, 04 Oct 2017 11:04:49 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
> Unless this problem (and that of Bug#28652) get fixed, we should either
> disable double buffering by default or add some special warning so users
> do not have to spend their time investigating this issue.

Isn't it strange that only some people see these problems, while
others (the majority?) are very happy with double-buffering?  Could it
be that the problems are triggered by some specific system
configurations or Emacs build-time features?  If so, we could perhaps
turn it off only for those configurations, because people who are
happy with this are extremely happy, and will probably be disappointed
if we just turn it off globally.




Added indication that bug 28695 blocks24655 Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Wed, 04 Oct 2017 09:35:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Wed, 04 Oct 2017 11:22:02 GMT) Full text and rfc822 format available.

Message #19 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Bryan Gilbert <bryan <at> bryan.sh>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, bryan <at> bryan.sh, 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on Linux
Date: Wed, 04 Oct 2017 07:21:55 -0400
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Isn't it strange that only some people see these problems, while
> others (the majority?) are very happy with double-buffering?  Could it
> be that the problems are triggered by some specific system
> configurations or Emacs build-time features?  If so, we could perhaps
> turn it off only for those configurations, because people who are
> happy with this are extremely happy, and will probably be disappointed
> if we just turn it off globally.

I'm currently using a Dell XPS 15 laptop with a 4K display and running
at a resolution of 3840x2160. I've noticed that the problem almost
entirely disappears when I resize the window to a smaller size (roughly
between 1/2 and 1/3 of the screen) instead of being fullscreen. It's
possible that this is only being noticed at higher resolutions.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Wed, 04 Oct 2017 11:38:01 GMT) Full text and rfc822 format available.

Message #22 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bryan Gilbert <bryan <at> bryan.sh>
Cc: rudalics <at> gmx.at, 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on Linux
Date: Wed, 04 Oct 2017 14:36:37 +0300
> From: Bryan Gilbert <bryan <at> bryan.sh>
> Cc: martin rudalics <rudalics <at> gmx.at>, bryan <at> bryan.sh, 28695 <at> debbugs.gnu.org
> Date: Wed, 04 Oct 2017 07:21:55 -0400
> 
> I'm currently using a Dell XPS 15 laptop with a 4K display and running
> at a resolution of 3840x2160. I've noticed that the problem almost
> entirely disappears when I resize the window to a smaller size (roughly
> between 1/2 and 1/3 of the screen) instead of being fullscreen. It's
> possible that this is only being noticed at higher resolutions.

Can you try lowering the screen resolution and using fullscreen Emacs
frames under that lower resolution?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Wed, 04 Oct 2017 12:03:02 GMT) Full text and rfc822 format available.

Message #25 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Bryan Gilbert <bryan <at> bryan.sh>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, Bryan Gilbert <bryan <at> bryan.sh>, 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on Linux
Date: Wed, 04 Oct 2017 08:02:44 -0400
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Can you try lowering the screen resolution and using fullscreen Emacs
> frames under that lower resolution?
>
> Thanks.

I just flipped the resolution down to 1080p and it became barely noticeable.
Here's is quick screen capture:

  http://drop.bryan.sh/UImFf4Rnzf.mp4

You can still slightly see it doing something weird with glxgears. However,
without that visual indication on the screen it feels almost on par with double
buffering being disabled.

I'll also mention that apart from this being reliably reproduced while using
counsel-rg, I've been hard pressed to notice it in other places. For a while,
I even thought that this may have been a bug with Ivy until I found the commit
that introduced the slowdown. This coupled with the possibility that it's only
visible at higher resolutions may be why many people aren't experiencing issues. 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Wed, 04 Oct 2017 12:33:02 GMT) Full text and rfc822 format available.

Message #28 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bryan Gilbert <bryan <at> bryan.sh>
Cc: rudalics <at> gmx.at, 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on Linux
Date: Wed, 04 Oct 2017 15:31:44 +0300
> From: Bryan Gilbert <bryan <at> bryan.sh>
> Cc: Bryan Gilbert <bryan <at> bryan.sh>, rudalics <at> gmx.at, 28695 <at> debbugs.gnu.org
> Date: Wed, 04 Oct 2017 08:02:44 -0400
> 
> I'll also mention that apart from this being reliably reproduced while using
> counsel-rg, I've been hard pressed to notice it in other places. For a while,
> I even thought that this may have been a bug with Ivy until I found the commit
> that introduced the slowdown. This coupled with the possibility that it's only
> visible at higher resolutions may be why many people aren't experiencing issues. 

Thanks.  Maybe we should indeed disable it by default for higher
resolutions.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Thu, 05 Oct 2017 13:38:01 GMT) Full text and rfc822 format available.

Message #31 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Bryan Gilbert <bryan <at> bryan.sh>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Thu, 5 Oct 2017 16:36:53 +0300
On 10/4/17 2:21 PM, Bryan Gilbert wrote:

>> Isn't it strange that only some people see these problems, while
>> others (the majority?) are very happy with double-buffering?  Could it
>> be that the problems are triggered by some specific system
>> configurations or Emacs build-time features?  If so, we could perhaps
>> turn it off only for those configurations, because people who are
>> happy with this are extremely happy, and will probably be disappointed
>> if we just turn it off globally.

Eli, perhaps it would be wise to ask the reporter if he'd like it to be 
turned off by default, if this problem can't be fixed in time.

Personally, I can stand a few minor glitches, given that double 
buffering saves me from flickering, which has been an annoyance for years.

> I'm currently using a Dell XPS 15 laptop with a 4K display and running
> at a resolution of 3840x2160.

Bryan, which revision/year is it? I also have an XPS 15 (with Skylake 
CPU) with 4K resolution, and at worst, I see the minor stutters you show 
in the 1080p video (after adding the advice, yes).

Ubuntu 17.04 with Unity 7 here.

I wasn't able to compare with the revision before double buffering, 
though: after checking out c29071587c64efb30792bd72248d3c791abd9337^, 
./autogen.sh says:

Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools.
Running 'autoreconf -fi -I m4' ...
/usr/bin/m4:aclocal.m4:9: cannot open `m4/count-leading-zeros.m4': No 
such file or directory
/usr/bin/m4:aclocal.m4:12: cannot open `m4/d-type.m4': No such file or 
directory
/usr/bin/m4:aclocal.m4:20: cannot open `m4/explicit_bzero.m4': No such 
file or directory
/usr/bin/m4:aclocal.m4:46: cannot open `m4/localtime-buffer.m4': No such 
file or directory
/usr/bin/m4:aclocal.m4:52: cannot open `m4/minmax.m4': No such file or 
directory
/usr/bin/m4:aclocal.m4:55: cannot open `m4/mode_t.m4': No such file or 
directory
/usr/bin/m4:aclocal.m4:58: cannot open `m4/nstrftime.m4': No such file 
or directory
/usr/bin/m4:aclocal.m4:60: cannot open `m4/open-cloexec.m4': No such 
file or directory
/usr/bin/m4:aclocal.m4:61: cannot open `m4/open.m4': No such file or 
directory
/usr/bin/m4:aclocal.m4:103: cannot open `m4/unlocked-io.m4': No such 
file or directory
autom4te: /usr/bin/m4 failed with exit status: 1
/usr/bin/m4:aclocal.m4:9: cannot open `m4/count-leading-zeros.m4': No 
such file or directory
/usr/bin/m4:aclocal.m4:12: cannot open `m4/d-type.m4': No such file or 
directory
/usr/bin/m4:aclocal.m4:20: cannot open `m4/explicit_bzero.m4': No such 
file or directory
/usr/bin/m4:aclocal.m4:46: cannot open `m4/localtime-buffer.m4': No such 
file or directory
/usr/bin/m4:aclocal.m4:52: cannot open `m4/minmax.m4': No such file or 
directory
/usr/bin/m4:aclocal.m4:55: cannot open `m4/mode_t.m4': No such file or 
directory
/usr/bin/m4:aclocal.m4:58: cannot open `m4/nstrftime.m4': No such file 
or directory
/usr/bin/m4:aclocal.m4:60: cannot open `m4/open-cloexec.m4': No such 
file or directory
/usr/bin/m4:aclocal.m4:61: cannot open `m4/open.m4': No such file or 
directory
/usr/bin/m4:aclocal.m4:103: cannot open `m4/unlocked-io.m4': No such 
file or directory
autom4te: /usr/bin/m4 failed with exit status: 1
autoreconf: /usr/bin/autoconf failed with exit status: 1




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Thu, 05 Oct 2017 14:02:02 GMT) Full text and rfc822 format available.

Message #34 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: bryan <at> bryan.sh, 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Thu, 05 Oct 2017 17:01:25 +0300
> Cc: 28695 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 5 Oct 2017 16:36:53 +0300
> 
> Eli, perhaps it would be wise to ask the reporter if he'd like it to be 
> turned off by default, if this problem can't be fixed in time.

I kinda did, by proposing the recipe to turn it off, and waiting for a
response ;-)

> Personally, I can stand a few minor glitches, given that double 
> buffering saves me from flickering, which has been an annoyance for years.

I know that you are very happy with this feature, which is why it
puzzles me how come you (and others who like it) don't see these
problems.

> I wasn't able to compare with the revision before double buffering, 
> though: after checking out c29071587c64efb30792bd72248d3c791abd9337^, 
> ./autogen.sh says:

It should be easier to use a previous release of Emacs, if you have it
or can install it.

Btw, the hardships of building an old enough checkout are the reason
why I keep old binaries around, and insist on not doing a bootstrap
(which nukes them).  I find this a much easier way of "bisecting", or
at least of having a good start point for looking for a change that
causes some bug.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Thu, 05 Oct 2017 14:03:01 GMT) Full text and rfc822 format available.

Message #37 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Bryan Gilbert <bryan <at> bryan.sh>,
 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Thu, 5 Oct 2017 10:02:21 -0400
On Thu, Oct 5, 2017 at 9:36 AM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> I wasn't able to compare with the revision before double buffering, though:
> after checking out c29071587c64efb30792bd72248d3c791abd9337^, ./autogen.sh
> says:

> Running 'autoreconf -fi -I m4' ...
> /usr/bin/m4:aclocal.m4:9: cannot open `m4/count-leading-zeros.m4': No such
> file or directory

Try 'rm aclocal.m4' (this is mentioned in INSTALL.REPO as of last May)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Thu, 05 Oct 2017 14:27:01 GMT) Full text and rfc822 format available.

Message #40 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Bryan Gilbert <bryan <at> bryan.sh>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Bryan Gilbert <bryan <at> bryan.sh>,
 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on Linux
Date: Thu, 05 Oct 2017 10:26:21 -0400
> Bryan, which revision/year is it? I also have an XPS 15 (with Skylake 
> CPU) with 4K resolution, and at worst, I see the minor stutters you show 
> in the 1080p video (after adding the advice, yes).

I'm using the newest model: XPS 9560 (Kaby Lake).

> Ubuntu 17.04 with Unity 7 here.

I'm running Arch Linux w/ XMonad.

> Personally, I can stand a few minor glitches, given that double 
> buffering saves me from flickering, which has been an annoyance for years.

I've never actually noticed flickering with Emacs in the ~2 years that I've
been using it, although I've seen it brought up often. One thing that is
unique about my setup compared to yours is that I have no compositor running,
and I'd assume that since you're running Unity that you most likely do. I'm
not sure if that would have any effect on this issue or the flickering though.
In either case I'll do a few tests with compton running to see if that makes
a difference.

I also have a co-worker with an identical computer running Gnome on X11, so
I'll see if I can get ahold of his computer and test this as well.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Sat, 07 Oct 2017 07:54:01 GMT) Full text and rfc822 format available.

Message #43 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Bryan Gilbert <bryan <at> bryan.sh>,
 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Sat, 7 Oct 2017 10:53:38 +0300
On 10/5/17 5:02 PM, Noam Postavsky wrote:

> Try 'rm aclocal.m4' (this is mentioned in INSTALL.REPO as of last May)

Thanks. Now I can confirm that when using the revision before 
double-buffering was added, glxgears indeed do not stutter at all 
(unlike the current emacs-26).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Sat, 07 Oct 2017 08:15:02 GMT) Full text and rfc822 format available.

Message #46 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 28695 <at> debbugs.gnu.org, bryan <at> bryan.sh, npostavs <at> users.sourceforge.net
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Sat, 07 Oct 2017 11:14:33 +0300
> Cc: Bryan Gilbert <bryan <at> bryan.sh>, Eli Zaretskii <eliz <at> gnu.org>,
>  28695 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 7 Oct 2017 10:53:38 +0300
> 
> On 10/5/17 5:02 PM, Noam Postavsky wrote:
> 
> > Try 'rm aclocal.m4' (this is mentioned in INSTALL.REPO as of last May)
> 
> Thanks. Now I can confirm that when using the revision before 
> double-buffering was added, glxgears indeed do not stutter at all 
> (unlike the current emacs-26).

Can some of you use a tool like perf to see whether the time taken by
XdbeSwapBuffers (called from xterm.c:show_back_buffer) indeed grows
significantly when going from the 2K class of resolutions to the 4K
class?  And if it isn't XdbeSwapBuffers, then what takes most of the
time which causes that "stutter"?

More generally, for some display operation to be perceptible as
"stutter", IME we should see that operation taking times around 50 to
100 msec.  Can we establish what part of frame/window update takes the
lion's share of that time when XDBE is used?  With that information in
hand, we may find some way forward with this issue.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Mon, 09 Oct 2017 13:54:02 GMT) Full text and rfc822 format available.

Message #49 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28695 <at> debbugs.gnu.org, bryan <at> bryan.sh, npostavs <at> users.sourceforge.net
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Mon, 9 Oct 2017 16:53:18 +0300
On 10/7/17 11:14 AM, Eli Zaretskii wrote:

> Can some of you use a tool like perf to see whether the time taken by
> XdbeSwapBuffers (called from xterm.c:show_back_buffer) indeed grows
> significantly when going from the 2K class of resolutions to the 4K
> class?  And if it isn't XdbeSwapBuffers, then what takes most of the
> time which causes that "stutter"?

With some pointers on how to use perf, I'd be happy to do that (or even 
without, if you're willing to wait).

But I'm not seeing a qualitative difference between a 4K fullscreen 
Emacs, a half-screen Emacs, or even Emacs with window resized further 
down: there are still minor stutters here. So I'm probably not the best 
person for this experiment.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Mon, 09 Oct 2017 14:05:03 GMT) Full text and rfc822 format available.

Message #52 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 28695 <at> debbugs.gnu.org, bryan <at> bryan.sh, npostavs <at> users.sourceforge.net
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Mon, 09 Oct 2017 17:03:37 +0300
> Cc: npostavs <at> users.sourceforge.net, bryan <at> bryan.sh, 28695 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 9 Oct 2017 16:53:18 +0300
> 
> On 10/7/17 11:14 AM, Eli Zaretskii wrote:
> 
> > Can some of you use a tool like perf to see whether the time taken by
> > XdbeSwapBuffers (called from xterm.c:show_back_buffer) indeed grows
> > significantly when going from the 2K class of resolutions to the 4K
> > class?  And if it isn't XdbeSwapBuffers, then what takes most of the
> > time which causes that "stutter"?
> 
> With some pointers on how to use perf, I'd be happy to do that

I think this page (which you probably already know about) is a good
starting point:

  http://www.brendangregg.com/perf.html

> (or even without, if you're willing to wait).

There's no rush, so please take your time.

> But I'm not seeing a qualitative difference between a 4K fullscreen 
> Emacs, a half-screen Emacs, or even Emacs with window resized further 
> down: there are still minor stutters here. So I'm probably not the best 
> person for this experiment.

Well, you saw a difference between a 4K display and a 2K display,
didn't you?  All we need is to compare 2 situations and see where's
the extra time spent.

Maybe Bryan could also try the profile, as he reported a significant
difference.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Sun, 15 Oct 2017 22:57:02 GMT) Full text and rfc822 format available.

Message #55 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28695 <at> debbugs.gnu.org, bryan <at> bryan.sh, npostavs <at> users.sourceforge.net
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Mon, 16 Oct 2017 01:55:54 +0300
On 10/9/17 5:03 PM, Eli Zaretskii wrote:

> I think this page (which you probably already know about) is a good
> starting point:
> 
>    http://www.brendangregg.com/perf.html

I still haven't found the appropriate recipe there, but somebody else on 
the internet suggested this, effectively:

sudo perf record -g src/emacs
# produces perf.data
sudo perf report -g -i perf.data

> Well, you saw a difference between a 4K display and a 2K display,
> didn't you?  All we need is to compare 2 situations and see where's
> the extra time spent.

A certain difference, but not a stark one. Like, I couldn't produce a 
full-on stuttering even with 4K (sometimes the gears continue spinning 
fine; probably has something to do with thread or process scheduling). 
With a small-window Emacs, the gears are spinning mostly fine.

Here are the window configurations:

1. Emacs fullscreen, 4K.
2. Emacs in a small window, much less than 2K.

Unfortunately, and if I'm reading the report right, XdbeSwapBuffers 
takes only 0,03% of CPU time in the first case and 0,02% in the second 
case. So, less than 1 percent in both cases.

Here's how it looks. I search for the function name in the report 
program, and it shows something like this:

  Children  Self   Comma  Shared Object     Symbol
  0,03%     0,03%  emacs  libXext.so.6.4.0  [.] XdbeSwapBuffers
  0,00%     0,00%  emacs  emacs             [.] XdbeSwapBuffers <at> plt

I'm not quite sure if perf.data contains sensitive information, but I'd 
be happy to send you the files produced by both scenarios for further 
analysis. Questions welcome, too.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Mon, 16 Oct 2017 02:31:02 GMT) Full text and rfc822 format available.

Message #58 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 28695 <at> debbugs.gnu.org, bryan <at> bryan.sh, npostavs <at> users.sourceforge.net
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Mon, 16 Oct 2017 05:30:49 +0300
> Cc: npostavs <at> users.sourceforge.net, bryan <at> bryan.sh, 28695 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 16 Oct 2017 01:55:54 +0300
> 
>    Children  Self   Comma  Shared Object     Symbol
>    0,03%     0,03%  emacs  libXext.so.6.4.0  [.] XdbeSwapBuffers
>    0,00%     0,00%  emacs  emacs             [.] XdbeSwapBuffers <at> plt

Hmm... so do you see any difference between these 2 scenarios in other
parts of the profiles?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Thu, 26 Oct 2017 23:20:02 GMT) Full text and rfc822 format available.

Message #61 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28695 <at> debbugs.gnu.org, bryan <at> bryan.sh, npostavs <at> users.sourceforge.net
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Fri, 27 Oct 2017 02:19:28 +0300
[Message part 1 (text/plain, inline)]
On 10/16/17 5:30 AM, Eli Zaretskii wrote:
>>     Children  Self   Comma  Shared Object     Symbol
>>     0,03%     0,03%  emacs  libXext.so.6.4.0  [.] XdbeSwapBuffers
>>     0,00%     0,00%  emacs  emacs             [.] XdbeSwapBuffers <at> plt
> 
> Hmm... so do you see any difference between these 2 scenarios in other
> parts of the profiles?

It's really hard for me to tell. Now, I've re-ran the experiment again 
(last time I did it with ag, now with rg) and I'm attaching the 
"unexpanded" views of the graphs in all cases. 1 and 11 were with a 
small window, and 2 and 22 were with a fullscreen one.

The search results for XdbeSwapBuffers were really similar to the above, 
so I'm not including that.

Don't really see a significant difference. If I had to guess, the 
slowdown maybe has to do with Xorg not being able to keep up, but, like, 
in an asynchronous fashion.
[perf.txt.1 (text/plain, attachment)]
[perf.txt.2 (text/plain, attachment)]
[perf.txt.11 (text/plain, attachment)]
[perf.txt.22 (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Sat, 28 Oct 2017 09:34:02 GMT) Full text and rfc822 format available.

Message #64 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 28695 <at> debbugs.gnu.org, bryan <at> bryan.sh, npostavs <at> users.sourceforge.net
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Sat, 28 Oct 2017 12:33:31 +0300
> Cc: npostavs <at> users.sourceforge.net, bryan <at> bryan.sh, 28695 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 27 Oct 2017 02:19:28 +0300
> 
> It's really hard for me to tell. Now, I've re-ran the experiment again 
> (last time I did it with ag, now with rg) and I'm attaching the 
> "unexpanded" views of the graphs in all cases. 1 and 11 were with a 
> small window, and 2 and 22 were with a fullscreen one.
> 
> The search results for XdbeSwapBuffers were really similar to the above, 
> so I'm not including that.
> 
> Don't really see a significant difference. If I had to guess, the 
> slowdown maybe has to do with Xorg not being able to keep up, but, like, 
> in an asynchronous fashion.

I don't see anything significant here, besides the fact that GC took
some serious percentage of time.

Thanks for your efforts.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Sat, 28 Oct 2017 21:48:02 GMT) Full text and rfc822 format available.

Message #67 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: eliz <at> gnu.org, bryan <at> bryan.sh, 28695 <at> debbugs.gnu.org,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#28695: 26.0.60;
 Rendering lag spikes caused by double-buffering on GNU/Linux
Date: Sat, 28 Oct 2017 17:47:35 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I doubt that this has anything to do with Linux in particular,
so it is probably about parts of the GNU system,  So would you please
say "GNU/Linux"?

See https://gnu.org/gnu/linux-and-gnu.html and
https://gnu.org/gnu/gnu-linux-faq.html, plus the history in
https://gnu.org/gnu/the-gnu-project.html.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Sat, 23 Apr 2022 13:47:02 GMT) Full text and rfc822 format available.

Message #70 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Bryan Gilbert <bryan <at> bryan.sh>
Cc: 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Sat, 23 Apr 2022 15:46:41 +0200
Bryan Gilbert <bryan <at> bryan.sh> writes:

> I've been using the Emacs 26 release branch and I've noticed a
> significant amount of rendering lag spikes. When this occurs the UI
> completely locks up in Emacs (and the desktop) for short periods of
> time. Better than an explanation I have two very short screencasts
> included below the display the behavior.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This was four years ago -- are you still seeing these issues in more
recent versions of Emacs (or the operating system)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 23 Apr 2022 13:47:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28695; Package emacs. (Sun, 22 May 2022 11:29:02 GMT) Full text and rfc822 format available.

Message #75 received at 28695 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Bryan Gilbert <bryan <at> bryan.sh>
Cc: 28695 <at> debbugs.gnu.org
Subject: Re: bug#28695: 26.0.60; Rendering lag spikes caused by
 double-buffering on Linux
Date: Sun, 22 May 2022 13:28:44 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> This was four years ago -- are you still seeing these issues in more
> recent versions of Emacs (or the operating system)?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 28695 <at> debbugs.gnu.org and Bryan Gilbert <bryan <at> bryan.sh> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 22 May 2022 11:29:04 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 20 Jun 2022 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 283 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.