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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 28695 <at> debbugs.gnu.org, bryan <at> bryan.sh, npostavs <at> users.sourceforge.net
Subject: bug#28695: 26.0.60; Rendering lag spikes caused by double-buffering on Linux
Date: Sat, 07 Oct 2017 11:14:33 +0300

> Cc: Bryan Gilbert <bryan <at> bryan.sh>, Eli Zaretskii <eliz <at> gnu.org>,
>  28695 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 7 Oct 2017 10:53:38 +0300
> 
> On 10/5/17 5:02 PM, Noam Postavsky wrote:
> 
> > Try 'rm aclocal.m4' (this is mentioned in INSTALL.REPO as of last May)
> 
> Thanks. Now I can confirm that when using the revision before 
> double-buffering was added, glxgears indeed do not stutter at all 
> (unlike the current emacs-26).

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

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

Thanks.

Previous Next

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