unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
@ 2017-10-04  3:10 Bryan Gilbert
  2017-10-04  7:53 ` Eli Zaretskii
                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Bryan Gilbert @ 2017-10-04  3:10 UTC (permalink / raw)
  To: 28695

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





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04  3:10 bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux Bryan Gilbert
@ 2017-10-04  7:53 ` Eli Zaretskii
  2017-10-04  9:04 ` martin rudalics
  2022-04-23 13:46 ` Lars Ingebrigtsen
  2 siblings, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-04  7:53 UTC (permalink / raw)
  To: Bryan Gilbert; +Cc: 28695

> From: Bryan Gilbert <bryan@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)))





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04  3:10 bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux Bryan Gilbert
  2017-10-04  7:53 ` Eli Zaretskii
@ 2017-10-04  9:04 ` martin rudalics
  2017-10-04  9:32   ` Eli Zaretskii
  2022-04-23 13:46 ` Lars Ingebrigtsen
  2 siblings, 1 reply; 23+ messages in thread
From: martin rudalics @ 2017-10-04  9:04 UTC (permalink / raw)
  To: Bryan Gilbert, 28695

 > 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





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04  9:04 ` martin rudalics
@ 2017-10-04  9:32   ` Eli Zaretskii
  2017-10-04 11:21     ` Bryan Gilbert
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-04  9:32 UTC (permalink / raw)
  To: martin rudalics; +Cc: bryan, 28695

> Date: Wed, 04 Oct 2017 11:04:49 +0200
> From: martin rudalics <rudalics@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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04  9:32   ` Eli Zaretskii
@ 2017-10-04 11:21     ` Bryan Gilbert
  2017-10-04 11:36       ` Eli Zaretskii
  2017-10-05 13:36       ` Dmitry Gutov
  0 siblings, 2 replies; 23+ messages in thread
From: Bryan Gilbert @ 2017-10-04 11:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: bryan, 28695


> Eli Zaretskii <eliz@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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04 11:21     ` Bryan Gilbert
@ 2017-10-04 11:36       ` Eli Zaretskii
  2017-10-04 12:02         ` Bryan Gilbert
  2017-10-05 13:36       ` Dmitry Gutov
  1 sibling, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-04 11:36 UTC (permalink / raw)
  To: Bryan Gilbert; +Cc: 28695

> From: Bryan Gilbert <bryan@bryan.sh>
> Cc: martin rudalics <rudalics@gmx.at>, bryan@bryan.sh, 28695@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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04 11:36       ` Eli Zaretskii
@ 2017-10-04 12:02         ` Bryan Gilbert
  2017-10-04 12:31           ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Bryan Gilbert @ 2017-10-04 12:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Bryan Gilbert, 28695


> Eli Zaretskii <eliz@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. 





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04 12:02         ` Bryan Gilbert
@ 2017-10-04 12:31           ` Eli Zaretskii
  0 siblings, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-04 12:31 UTC (permalink / raw)
  To: Bryan Gilbert; +Cc: 28695

> From: Bryan Gilbert <bryan@bryan.sh>
> Cc: Bryan Gilbert <bryan@bryan.sh>, rudalics@gmx.at, 28695@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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04 11:21     ` Bryan Gilbert
  2017-10-04 11:36       ` Eli Zaretskii
@ 2017-10-05 13:36       ` Dmitry Gutov
  2017-10-05 14:01         ` Eli Zaretskii
                           ` (2 more replies)
  1 sibling, 3 replies; 23+ messages in thread
From: Dmitry Gutov @ 2017-10-05 13:36 UTC (permalink / raw)
  To: Bryan Gilbert, Eli Zaretskii; +Cc: 28695

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





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-05 13:36       ` Dmitry Gutov
@ 2017-10-05 14:01         ` Eli Zaretskii
  2017-10-05 14:02         ` Noam Postavsky
  2017-10-05 14:26         ` bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux Bryan Gilbert
  2 siblings, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-05 14:01 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: bryan, 28695

> Cc: 28695@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-05 13:36       ` Dmitry Gutov
  2017-10-05 14:01         ` Eli Zaretskii
@ 2017-10-05 14:02         ` Noam Postavsky
  2017-10-07  7:53           ` Dmitry Gutov
  2017-10-05 14:26         ` bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux Bryan Gilbert
  2 siblings, 1 reply; 23+ messages in thread
From: Noam Postavsky @ 2017-10-05 14:02 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Bryan Gilbert, 28695

On Thu, Oct 5, 2017 at 9:36 AM, Dmitry Gutov <dgutov@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)





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-05 13:36       ` Dmitry Gutov
  2017-10-05 14:01         ` Eli Zaretskii
  2017-10-05 14:02         ` Noam Postavsky
@ 2017-10-05 14:26         ` Bryan Gilbert
  2 siblings, 0 replies; 23+ messages in thread
From: Bryan Gilbert @ 2017-10-05 14:26 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Bryan Gilbert, 28695


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





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-05 14:02         ` Noam Postavsky
@ 2017-10-07  7:53           ` Dmitry Gutov
  2017-10-07  8:14             ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Dmitry Gutov @ 2017-10-07  7:53 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: Bryan Gilbert, 28695

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





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-07  7:53           ` Dmitry Gutov
@ 2017-10-07  8:14             ` Eli Zaretskii
  2017-10-09 13:53               ` Dmitry Gutov
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-07  8:14 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: npostavs, 28695, bryan

> Cc: Bryan Gilbert <bryan@bryan.sh>, Eli Zaretskii <eliz@gnu.org>,
>  28695@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-07  8:14             ` Eli Zaretskii
@ 2017-10-09 13:53               ` Dmitry Gutov
  2017-10-09 14:03                 ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Dmitry Gutov @ 2017-10-09 13:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: npostavs, 28695, bryan

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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-09 13:53               ` Dmitry Gutov
@ 2017-10-09 14:03                 ` Eli Zaretskii
  2017-10-15 22:55                   ` Dmitry Gutov
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-09 14:03 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: npostavs, 28695, bryan

> Cc: npostavs@users.sourceforge.net, bryan@bryan.sh, 28695@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-09 14:03                 ` Eli Zaretskii
@ 2017-10-15 22:55                   ` Dmitry Gutov
  2017-10-16  2:30                     ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Dmitry Gutov @ 2017-10-15 22:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: npostavs, 28695, bryan

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





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-15 22:55                   ` Dmitry Gutov
@ 2017-10-16  2:30                     ` Eli Zaretskii
  2017-10-26 23:19                       ` Dmitry Gutov
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-16  2:30 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: npostavs, 28695, bryan

> Cc: npostavs@users.sourceforge.net, bryan@bryan.sh, 28695@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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@plt

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

Thanks.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-16  2:30                     ` Eli Zaretskii
@ 2017-10-26 23:19                       ` Dmitry Gutov
  2017-10-28  9:33                         ` Eli Zaretskii
  2017-10-28 21:47                         ` bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on GNU/Linux Richard Stallman
  0 siblings, 2 replies; 23+ messages in thread
From: Dmitry Gutov @ 2017-10-26 23:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: npostavs, 28695, bryan

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

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

[-- Attachment #2: perf.txt.1 --]
[-- Type: text/plain, Size: 4525 bytes --]

Samples: 60K of event 'cycles', Event count (approx.): 26885534358
  Children      Self  Command       Shared Object               Symbol
+   23,18%    23,08%  emacs         emacs                       [.] mark_object
+   15,20%     0,00%  emacs         [unknown]                   [.] 0xfff42db4fff42ca2
+    8,17%     0,00%  rg            rg                          [.] 0xffffffffffdd4fed
+    8,07%     0,00%  rg            rg                          [.] 0xffffffffffdcd70c
+    8,07%     0,00%  rg            rg                          [.] 0xffffffffffde1deb
+    8,07%     0,00%  rg            rg                          [.] 0xffffffffffc03250
+    8,07%     0,00%  rg            rg                          [.] 0xffffffffffc05020
+    8,07%     0,00%  rg            rg                          [.] 0xffffffffffc1294f
+    7,22%     2,56%  emacs         emacs                       [.] re_search_2
+    6,07%     0,00%  rg            rg                          [.] 0xffffffffffcfad8b
+    6,06%     0,00%  rg            rg                          [.] 0xffffffffffc484a8
+    6,03%     0,00%  rg            rg                          [.] 0xffffffffffc3ef09
+    4,96%     0,00%  rg            [kernel.kallsyms]           [k] entry_SYSCALL_64_fastpath
+    4,87%     0,00%  emacs         [unknown]                   [.] 0000000000000000
+    4,28%     0,00%  rg            rg                          [.] 0xffffffffffde39c6
+    4,22%     4,18%  emacs         emacs                       [.] assq_no_quit
+    4,18%     0,21%  emacs         emacs                       [.] funcall_lambda
+    4,16%     0,00%  rg            rg                          [.] 0xffffffffffc3b175
+    4,03%     0,01%  emacs         [kernel.kallsyms]           [k] entry_SYSCALL_64_fastpath
+    3,91%     3,90%  emacs         emacs                       [.] re_match_2_internal
+    3,82%     0,00%  rg            rg                          [.] 0xffffffffffc3f014
+    3,76%     0,00%  rg            [kernel.kallsyms]           [k] sys_write
+    3,76%     0,00%  rg            [kernel.kallsyms]           [k] vfs_write
+    3,75%     0,00%  rg            [kernel.kallsyms]           [k] __vfs_write
+    3,75%     0,01%  rg            [kernel.kallsyms]           [k] tty_write
+    3,65%     0,00%  rg            rg                          [.] 0xffffffffffc2e3d8
+    3,44%     0,93%  rg            [kernel.kallsyms]           [k] n_tty_write
     2,98%     2,97%  emacs         emacs                       [.] sweep_strings
+    2,92%     2,90%  emacs         emacs                       [.] exec_byte_code
+    2,16%     0,00%  rg            rg                          [.] 0xffffffffffc312d7
+    1,97%     0,05%  rg            [kernel.kallsyms]           [k] pty_write
+    1,87%     0,00%  rg            rg                          [.] 0xffffffffffc034a0
+    1,80%     0,00%  rg            rg                          [.] 0xffffffffffdba822
+    1,77%     0,00%  rg            rg                          [.] 0xffffffffffc2eda9
+    1,70%     0,03%  rg            [kernel.kallsyms]           [k] tty_flip_buffer_push
+    1,67%     1,65%  emacs         emacs                       [.] decode_coding_utf_8
+    1,67%     0,22%  rg            [kernel.kallsyms]           [k] queue_work_on
+    1,59%     1,59%  emacs         emacs                       [.] Fassq
+    1,44%     1,42%  emacs         emacs                       [.] produce_chars
+    1,43%     1,43%  emacs         emacs                       [.] sweep_conses
+    1,32%     0,11%  rg            [kernel.kallsyms]           [k] __queue_work
+    1,24%     0,00%  rg            rg                          [.] 0xffffffffffc3ac4b
+    1,23%     0,00%  emacs         [unknown]                   [.] 0x000000000086df0c
+    1,18%     0,19%  rg            [kernel.kallsyms]           [k] insert_work
+    1,03%     0,00%  emacs         libpthread-2.24.so          [.] 0xffff80b2c50c8d8d
+    1,02%     0,00%  emacs         [kernel.kallsyms]           [k] sys_open
+    1,01%     0,00%  emacs         [kernel.kallsyms]           [k] do_sys_open
+    1,00%     0,01%  rg            [kernel.kallsyms]           [k] wake_up_process
+    0,99%     0,00%  rg            rg                          [.] 0xffffffffffc31158
     0,99%     0,98%  emacs         emacs                       [.] string_char_to_byte
+    0,98%     0,19%  rg            [kernel.kallsyms]           [k] try_to_wake_up
+    0,94%     0,01%  emacs         libc-2.24.so                [.] __GI___writev

[-- Attachment #3: perf.txt.2 --]
[-- Type: text/plain, Size: 4719 bytes --]

Samples: 93K of event 'cycles', Event count (approx.): 38670648824
  Children      Self  Command       Shared Object                  Symbol
+   26,75%    26,60%  emacs         emacs                          [.] mark_object
+   17,52%     0,00%  emacs         [unknown]                      [k] 0xfff42db4fff42ca2
+    7,85%     3,86%  emacs         emacs                          [.] re_search_2
+    6,08%     0,00%  rg            rg                             [.] 0xffffffffffdd4fed
+    5,96%     0,00%  rg            rg                             [.] 0xffffffffffdcd70c
+    5,96%     0,00%  rg            rg                             [.] 0xffffffffffde1deb
+    5,96%     0,00%  rg            rg                             [.] 0xffffffffffc03250
+    5,96%     0,00%  rg            rg                             [.] 0xffffffffffc05020
+    5,96%     0,00%  rg            rg                             [.] 0xffffffffffc1294f
+    5,79%     0,21%  emacs         emacs                          [.] funcall_lambda
+    4,81%     4,79%  emacs         emacs                          [.] sweep_strings
+    4,41%     0,00%  emacs         [unknown]                      [.] 0000000000000000
+    4,31%     0,00%  rg            rg                             [.] 0xffffffffffcfad8b
+    4,28%     0,00%  rg            rg                             [.] 0xffffffffffc484a8
+    4,26%     0,00%  rg            rg                             [.] 0xffffffffffc3ef09
+    4,20%     4,18%  emacs         emacs                          [.] exec_byte_code
+    3,47%     3,44%  emacs         emacs                          [.] assq_no_quit
+    3,44%     3,42%  emacs         emacs                          [.] re_match_2_internal
+    3,39%     0,00%  rg            [kernel.kallsyms]              [k] entry_SYSCALL_64_fastpath
+    3,16%     0,01%  emacs         [kernel.kallsyms]              [k] entry_SYSCALL_64_fastpath
+    2,89%     0,00%  rg            rg                             [.] 0xffffffffffc3b175
+    2,82%     0,00%  rg            rg                             [.] 0xffffffffffde39c6
+    2,53%     0,00%  rg            rg                             [.] 0xffffffffffc2e3d8
+    2,44%     0,00%  rg            rg                             [.] 0xffffffffffc3f014
+    2,39%     0,00%  rg            [kernel.kallsyms]              [k] sys_write
+    2,39%     0,00%  rg            [kernel.kallsyms]              [k] vfs_write
+    2,39%     0,00%  rg            [kernel.kallsyms]              [k] __vfs_write
+    2,38%     0,01%  rg            [kernel.kallsyms]              [k] tty_write
+    2,18%     0,61%  rg            [kernel.kallsyms]              [k] n_tty_write
     1,74%     1,73%  emacs         emacs                          [.] string_char_to_byte
+    1,47%     0,00%  rg            rg                             [.] 0xffffffffffc312d7
+    1,42%     1,41%  emacs         emacs                          [.] sweep_conses
+    1,33%     0,00%  emacs         [unknown]                      [.] 0xffffffc750e90000
+    1,28%     0,00%  rg            rg                             [.] 0xffffffffffc034a0
+    1,26%     0,00%  emacs         [unknown]                      [.] 0x000000000086df0c
+    1,26%     0,00%  rg            rg                             [.] 0xffffffffffc2eda9
+    1,24%     0,00%  rg            rg                             [.] 0xffffffffffdba822
+    1,24%     0,86%  emacs         libc-2.24.so                   [.] __memmove_avx_unaligned_erms
+    1,15%     0,03%  rg            [kernel.kallsyms]              [k] pty_write
+    1,14%     1,14%  emacs         emacs                          [.] Fassq
     1,12%     1,11%  emacs         emacs                          [.] sweep_vectors
+    1,04%     0,87%  emacs         emacs                          [.] Ffuncall
+    0,99%     0,98%  emacs         emacs                          [.] decode_coding_utf_8
+    0,96%     0,02%  rg            [kernel.kallsyms]              [k] tty_flip_buffer_push
+    0,94%     0,12%  rg            [kernel.kallsyms]              [k] queue_work_on
+    0,93%     0,91%  emacs         emacs                          [.] mark_char_table
+    0,91%     0,90%  emacs         emacs                          [.] produce_chars
+    0,89%     0,00%  rg            rg                             [.] 0xffffffffffc3ac4b
+    0,89%     0,00%  emacs         [unknown]                      [.] 0x08d347d3c0810700
     0,87%     0,86%  emacs         emacs                          [.] find_cache_boundary
+    0,86%     0,85%  emacs         emacs                          [.] buf_charpos_to_bytepos
+    0,83%     0,01%  emacs         libc-2.24.so                   [.] __GI___writev


[-- Attachment #4: perf.txt.11 --]
[-- Type: text/plain, Size: 4852 bytes --]

Samples: 108K of event 'cycles', Event count (approx.): 46413756102
  Children      Self  Command       Shared Object                     Symbol
+   24,40%    24,29%  emacs         emacs                             [.] mark_object
+   16,05%     0,00%  emacs         [unknown]                         [.] 0xfff42db4fff42ca2
+    6,60%     3,38%  emacs         emacs                             [.] re_search_2
+    6,19%     0,00%  rg            rg                                [.] 0xffffffffffdd4fed
+    6,13%     0,00%  rg            rg                                [.] 0xffffffffffdcd70c
+    6,13%     0,00%  rg            rg                                [.] 0xffffffffffde1deb
+    6,13%     0,00%  rg            rg                                [.] 0xffffffffffc03250
+    6,13%     0,00%  rg            rg                                [.] 0xffffffffffc05020
+    6,13%     0,00%  rg            rg                                [.] 0xffffffffffc1294f
+    5,09%     0,00%  rg            [kernel.kallsyms]                 [k] entry_SYSCALL_64_fastpath
+    4,88%     0,21%  emacs         emacs                             [.] funcall_lambda
+    4,80%     0,00%  rg            rg                                [.] 0xffffffffffcfad8b
+    4,77%     0,00%  rg            rg                                [.] 0xffffffffffc484a8
+    4,74%     0,00%  rg            rg                                [.] 0xffffffffffc3ef09
+    4,69%     0,00%  emacs         [unknown]                         [.] 0000000000000000
+    4,62%     4,57%  emacs         emacs                             [.] assq_no_quit
+    4,57%     0,00%  rg            rg                                [.] 0xffffffffffde39c6
+    4,15%     0,00%  rg            [kernel.kallsyms]                 [k] vfs_write
+    4,15%     0,00%  rg            [kernel.kallsyms]                 [k] sys_write
+    4,15%     0,00%  rg            [kernel.kallsyms]                 [k] __vfs_write
+    4,15%     0,01%  rg            [kernel.kallsyms]                 [k] tty_write
+    4,04%     0,00%  rg            rg                                [.] 0xffffffffffc3f014
+    3,82%     1,14%  rg            [kernel.kallsyms]                 [k] n_tty_write
+    3,59%     3,58%  emacs         emacs                             [.] exec_byte_code
+    3,57%     0,01%  emacs         [kernel.kallsyms]                 [k] entry_SYSCALL_64_fastpath
     3,51%     3,50%  emacs         emacs                             [.] sweep_strings
+    3,32%     0,00%  rg            rg                                [.] 0xffffffffffc3b175
+    2,91%     0,00%  rg            rg                                [.] 0xffffffffffc2e3d8
+    2,83%     2,82%  emacs         emacs                             [.] re_match_2_internal
+    2,14%     0,05%  rg            [kernel.kallsyms]                 [k] pty_write
+    1,89%     1,87%  emacs         emacs                             [.] decode_coding_utf_8
+    1,80%     0,02%  rg            [kernel.kallsyms]                 [k] tty_flip_buffer_push
+    1,78%     0,25%  rg            [kernel.kallsyms]                 [k] queue_work_on
+    1,72%     0,00%  rg            rg                                [.] 0xffffffffffc312d7
+    1,68%     1,66%  emacs         emacs                             [.] produce_chars
     1,61%     1,60%  emacs         emacs                             [.] string_char_to_byte
+    1,46%     0,00%  rg            rg                                [.] 0xffffffffffc034a0
+    1,41%     0,00%  rg            rg                                [.] 0xffffffffffc2eda9
+    1,40%     0,11%  rg            [kernel.kallsyms]                 [k] __queue_work
+    1,40%     0,00%  rg            rg                                [.] 0xffffffffffdba822
+    1,34%     0,00%  emacs         [unknown]                         [.] 0x100000000003e8f3
+    1,33%     1,32%  emacs         emacs                             [.] sweep_conses
+    1,26%     0,19%  rg            [kernel.kallsyms]                 [k] insert_work
+    1,20%     0,00%  emacs         [unknown]                         [.] 0x000000000086df0c
+    1,09%     1,09%  emacs         emacs                             [.] Fassq
     1,09%     1,09%  emacs         emacs                             [.] buf_bytepos_to_charpos
+    1,08%     0,00%  rg            [kernel.kallsyms]                 [k] wake_up_process
+    1,05%     0,18%  rg            [kernel.kallsyms]                 [k] try_to_wake_up
+    1,03%     0,01%  emacs         libc-2.24.so                      [.] __GI___writev
+    1,01%     0,01%  emacs         [kernel.kallsyms]                 [k] sys_writev
+    0,99%     0,98%  emacs         emacs                             [.] set_buffer_internal_2
+    0,99%     0,01%  emacs         [kernel.kallsyms]                 [k] do_writev


[-- Attachment #5: perf.txt.22 --]
[-- Type: text/plain, Size: 4544 bytes --]

Samples: 119K of event 'cycles', Event count (approx.): 49609855919
  Children      Self  Command       Shared Object               Symbol
+   28,68%    28,51%  emacs         emacs                       [.] mark_object
+   18,60%     0,00%  emacs         [unknown]                   [k] 0xfff42db4fff42ca2
+    6,76%     3,54%  emacs         emacs                       [.] re_search_2
+    5,94%     0,00%  rg            rg                          [.] 0xffffffffffdd4fed
+    5,85%     0,00%  rg            rg                          [.] 0xffffffffffdcd70c
+    5,85%     0,00%  rg            rg                          [.] 0xffffffffffde1deb
+    5,85%     0,00%  rg            rg                          [.] 0xffffffffffc03250
+    5,85%     0,00%  rg            rg                          [.] 0xffffffffffc05020
+    5,85%     0,00%  rg            rg                          [.] 0xffffffffffc1294f
+    5,23%     0,18%  emacs         emacs                       [.] funcall_lambda
+    4,94%     0,00%  emacs         [unknown]                   [.] 0000000000000000
+    4,85%     4,82%  emacs         emacs                       [.] sweep_strings
+    4,50%     0,00%  rg            rg                          [.] 0xffffffffffcfad8b
+    4,28%     0,00%  rg            rg                          [.] 0xffffffffffc484a8
+    4,25%     0,00%  rg            rg                          [.] 0xffffffffffc3ef09
+    4,05%     4,02%  emacs         emacs                       [.] assq_no_quit
+    3,78%     3,76%  emacs         emacs                       [.] exec_byte_code
+    3,68%     0,00%  rg            [kernel.kallsyms]           [k] entry_SYSCALL_64_fastpath
+    3,19%     0,00%  rg            rg                          [.] 0xffffffffffde39c6
+    2,99%     0,01%  emacs         [kernel.kallsyms]           [k] entry_SYSCALL_64_fastpath
+    2,92%     0,00%  rg            rg                          [.] 0xffffffffffc3b175
+    2,80%     2,79%  emacs         emacs                       [.] re_match_2_internal
+    2,79%     0,00%  rg            [kernel.kallsyms]           [k] sys_write
+    2,79%     0,00%  rg            [kernel.kallsyms]           [k] vfs_write
+    2,79%     0,00%  rg            [kernel.kallsyms]           [k] __vfs_write
+    2,78%     0,01%  rg            [kernel.kallsyms]           [k] tty_write
+    2,60%     0,00%  rg            rg                          [.] 0xffffffffffc3f014
+    2,56%     0,71%  rg            [kernel.kallsyms]           [k] n_tty_write
+    2,51%     0,00%  rg            rg                          [.] 0xffffffffffc2e3d8
     1,62%     1,61%  emacs         emacs                       [.] string_char_to_byte
+    1,41%     0,00%  rg            rg                          [.] 0xffffffffffc312d7
+    1,39%     0,03%  rg            [kernel.kallsyms]           [k] pty_write
+    1,38%     1,37%  emacs         emacs                       [.] sweep_conses
+    1,36%     0,00%  emacs         [unknown]                   [.] 0x000000000086df0c
+    1,24%     0,00%  rg            rg                          [.] 0xffffffffffc2eda9
+    1,21%     0,00%  rg            rg                          [.] 0xffffffffffc034a0
     1,19%     1,18%  emacs         emacs                       [.] sweep_vectors
+    1,19%     0,02%  rg            [kernel.kallsyms]           [k] tty_flip_buffer_push
+    1,17%     0,14%  rg            [kernel.kallsyms]           [k] queue_work_on
+    1,15%     0,00%  rg            rg                          [.] 0xffffffffffdba822
+    1,06%     1,04%  emacs         emacs                       [.] decode_coding_utf_8
+    1,05%     0,87%  emacs         emacs                       [.] Ffuncall
     1,04%     0,84%  emacs         libc-2.24.so                [.] __memmove_avx_unaligned_erms
+    0,97%     0,96%  emacs         emacs                       [.] mark_char_table
+    0,97%     0,95%  emacs         emacs                       [.] produce_chars
+    0,94%     0,06%  rg            [kernel.kallsyms]           [k] __queue_work
+    0,94%     0,93%  emacs         emacs                       [.] Fassq
     0,88%     0,87%  emacs         emacs                       [.] find_cache_boundary
+    0,87%     0,00%  rg            rg                          [.] 0xffffffffffc3ac4b
+    0,86%     0,10%  rg            [kernel.kallsyms]           [k] insert_work
+    0,86%     0,02%  emacs         libc-2.24.so                [.] __GI___writev
+    0,85%     0,00%  emacs         [unknown]                   [.] 0xbdbe522fc9012600


^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-26 23:19                       ` Dmitry Gutov
@ 2017-10-28  9:33                         ` Eli Zaretskii
  2017-10-28 21:47                         ` bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on GNU/Linux Richard Stallman
  1 sibling, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2017-10-28  9:33 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: npostavs, 28695, bryan

> Cc: npostavs@users.sourceforge.net, bryan@bryan.sh, 28695@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on GNU/Linux
  2017-10-26 23:19                       ` Dmitry Gutov
  2017-10-28  9:33                         ` Eli Zaretskii
@ 2017-10-28 21:47                         ` Richard Stallman
  1 sibling, 0 replies; 23+ messages in thread
From: Richard Stallman @ 2017-10-28 21:47 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: npostavs, bryan, 28695

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






^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2017-10-04  3:10 bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux Bryan Gilbert
  2017-10-04  7:53 ` Eli Zaretskii
  2017-10-04  9:04 ` martin rudalics
@ 2022-04-23 13:46 ` Lars Ingebrigtsen
  2022-05-22 11:28   ` Lars Ingebrigtsen
  2 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-23 13:46 UTC (permalink / raw)
  To: Bryan Gilbert; +Cc: 28695

Bryan Gilbert <bryan@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





^ permalink raw reply	[flat|nested] 23+ messages in thread

* bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
  2022-04-23 13:46 ` Lars Ingebrigtsen
@ 2022-05-22 11:28   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 23+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-22 11:28 UTC (permalink / raw)
  To: Bryan Gilbert; +Cc: 28695

Lars Ingebrigtsen <larsi@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





^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2022-05-22 11:28 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-04  3:10 bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux Bryan Gilbert
2017-10-04  7:53 ` Eli Zaretskii
2017-10-04  9:04 ` martin rudalics
2017-10-04  9:32   ` Eli Zaretskii
2017-10-04 11:21     ` Bryan Gilbert
2017-10-04 11:36       ` Eli Zaretskii
2017-10-04 12:02         ` Bryan Gilbert
2017-10-04 12:31           ` Eli Zaretskii
2017-10-05 13:36       ` Dmitry Gutov
2017-10-05 14:01         ` Eli Zaretskii
2017-10-05 14:02         ` Noam Postavsky
2017-10-07  7:53           ` Dmitry Gutov
2017-10-07  8:14             ` Eli Zaretskii
2017-10-09 13:53               ` Dmitry Gutov
2017-10-09 14:03                 ` Eli Zaretskii
2017-10-15 22:55                   ` Dmitry Gutov
2017-10-16  2:30                     ` Eli Zaretskii
2017-10-26 23:19                       ` Dmitry Gutov
2017-10-28  9:33                         ` Eli Zaretskii
2017-10-28 21:47                         ` bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on GNU/Linux Richard Stallman
2017-10-05 14:26         ` bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux Bryan Gilbert
2022-04-23 13:46 ` Lars Ingebrigtsen
2022-05-22 11:28   ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).