* 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 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-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-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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.