Redraw lag with NVIDIA 334.21 driver

[tchebb]

Since upgrading to NVIDIA's 334.21 driver, I've been seeing some odd input lag issues when using compton. The lag is most noticeable when scrolling using the scroll-wheel in Firefox. Right after starting Firefox, it's smooth and snappy as expected. But once I've had it open for a while (rapidly changing focus to and from another window seems to trigger it more quickly), my scroll position ends up "one behind." For example, if I scroll down two clicks then up one, I see the page position I'd expect to see after the second down click only after I do the up click. In order to see the results of the up click, I need to either perform another scroll action, change focus to a different window, or trigger a redraw in some other way. The only reliable way to get rid of the issue seems to be to restart Firefox.

Some Googling led me to this Clutter bug report, which has similar symptoms and was caused by a change to NVIDIA's GLX_EXT_buffer_age handling. Although I wasn't using glx-swap-method = "buffer-age"; to begin with, after adding it I saw the same flickering that was reported in the linked NVIDIA forum thread in addition to the original redraw lag.

Could there be a single bug in compton that's causing both issues, and if so, what can I do to help fix it? I've already looked through compton's buffer_age handling code, but I have very limited experience with graphics and couldn't find anything obviously wrong.

A copy of my configuration file follows:

backend = "glx";
glx-no-stencil = true;
glx-no-rebind-pixmap = true;

vsync = "opengl-swc";
paint-on-overlay = true;

I can confirm this; here's some additional info about it:
https://bbs.archlinux.org/viewtopic.php?id=178024
https://devtalk.nvidia.com/default/topic/700104/linux/screen-jittering-with-334-21/

[bucaneer]

I had this happen with --glx-swap-method 2 but then switched to 3 and everything appears to work fine as it did before driver upgrade.

Well, with swap method 3, the redrawing lags in firefox seem to be gone, but they are still present in programs like termite for example… They become very obvious if you navigate around in ranger; sometimes, the reaction of a keypress takes over a second! Downgrading nvidia solves this problem for the moment, but this isn't a real solution of course.

Edit: Another workaround seems to be to use xr_glx_hybrid, I'll test on this later…

[tchebb]

To RichardGv, who I was talking with in IRC earlier today: unfortunately, the screen capture I took (using gtk-RecordMyDesktop) of the symptoms with MONITOR_REPAINT enabled doesn't appear to have captured either the slow flickering I mentioned or the outdated regions that this bug report is about. That in and of itself might be useful information, but I don't think that attaching the video will be of much use.

[richardgv]

@tchebb:

Oh, could you please install apitrace, a tiny GL debugging tool (please build from git repo, the stable version lacks the functionality to debug a compositor), trace compton with it (MONITOR_REPAINT + apitrace trace --config /dev/null --backend glx --glx-swap-method 1), and attach the trace file?

@cju:

If you are using TripleBuffer in xorg.conf, --glx-swap-method 4 might be needed.

[richardgv]

Yet another day and I'm having absolutely no luck dealing with the --glx-swap-method buffer-age issue. The only possible workaround I know is to use a --glx-swap-method value larger than normal (use 3 for double buffered screen, and 4 for triple-buffered). The clutter patch actually (unintentionally?) makes mutter unions current damage region with buffer_age last damaged regions instead of buffer_age - 1 regions, which is what we uses and what I believe is correct according to the specification. Kwin and a weston patch ( http://lists.freedesktop.org/archives/wayland-devel/2013-March/007790.html ) probably uses buffer_age - 1, but strangely enough the issue doesn't appear on them. A comment on KDE review board seemingly indicates nvidia-drivers is returning wrong buffer_age. nVidia guys claimed they corrected the wrong buffer_age value, but as far as I could remember, it's returning 2 for double-buffered setups and it has been causing artifacts here since we introduced --glx-swap-method buffer-age -- I'm always using --glx-swap-method 3 personally. What makes tracing particularly tricky is I found no reliable way to reproduce the issue -- looks like it appears randomly here. nvidia-drivers do double-buffering correctly intially but after a while something will get messed up... So frustrating it is.

Sorry, none of the swap-methods and none xorg buffer option resolves this problem for me... In case that matters, I'm testing with the latest git version of termite. As I said before, only using the hybrid backend (or just native xrender, of course) seems to solve this, that's why I burried out #163 once again… ;)

[richardgv]

@cju:

But you could simply avoid using --glx-swap-method, right? The optimization isn't really necessary if your GPU is strong enough. Or you meant the issue appears without --glx-swap-method as well? I see both the links you provided are about the buffer_age issue.

[roman-holovin]

@richardgv no, it is lagging with any swap method, including undefined.

[richardgv]

Heh, I see. The nVidia guy talked about synchronization issue and EXT_x11_sync_object, but I don't see any big compositors using it right now. (Another nVidia employee added some sort of EXT_x11_sync_object support to his own fork of Compiz, though.) I don't see a clear way to utilize X Sync extension and EXT_x11_sync_object in a compositor, either. I will try to add some synchronization code to some possibly problematic places tomorrow, to check if it brings any changes.

[richardgv]

Hmm, I'm truly sorry for the delay... Here's a patch that adds X Sync fence support to compton: https://gist.github.com/richardgv/9529221

Using a nVidia-proposed feature to deal with a problem on nvidia-drivers sounds like a nice idea. :-D Seemingly the --glx-swap-method buffer-age issue didn't occur after I apply the patch, at least. However it's not effective against the flickering issue of xr_glx_hybrid backend, might indicate potential problems in my implementation. (Yeah, I should run xrender_sync for 49 times before painting. :-D) (Or I would simply need EXT_x11_sync_object? Does anybody know the difference between XSyncAwaitFence() and EXT_x11_sync_object?) Fence is still a relatively new feature that may not be available to BSD users (worse yet, it may fail to compile with older libXext), which would surely be a problem if I wish to merge it, though.

[roman-holovin]

Well, I'm using compton from current master with this patch for a few hours and it works. Thank you.

[evanpurkhiser]

For any Arch users out there that want to test out the patch, here's a PKGBUILD.