Compton w/ glx-backend causes lags in xterm, urxvt and dmenu when using xft-fonts

[ghost]

When I run compton with the glx-backend, I get visual hangs/lags/glitches in xterm, urxvt and dmenu – but ONLY when I use xft respectively a xft-font!

For example:

• If I switch the selected item in dmenu, it "stutters" a lot.
• If I browse in xterm/urxvt through ranger or move around htop, the highlighting/selection of an item hangs a few seconds before moving to the next. Sometimes, the delays between the "visual refreshments" last 2-3 seconds.

As soon as I switch back to a bitmap font, the problem seems to be gone!

I am running the latest version of compton under i3 with a nvidia chipset and the nvidia-driver. If there is any additional information that might by helpful, please let me know.

TIA

P.S. Obviously, this isn't happening in VTE-based applications by using xft-fonts there, though.

[richardgv]

Sorry if the stuffs below looks disorganized. I'm tired today...

• I would recommend you to hand the issue to the Xorg developer or nVidia guys. A compositor does not care about how the content of a window is drawn, so if Xft triggers the issue, most likely it isn't our problem.

• 147 looks somewhat similar to your issue. It's a bug in nvidia-drivers that it fails to report window content changes (DamageNotify) to us in time under unclear situtations.

• "Latest version of compton" or nvidia-drivers is typically an accurate description, because it may depend on the distro, version of your distro, or the time you built your package. Please tell us the exact version numbers. You could see the version of compton with compton -h | head -n1.
• You are recommended to tell us the exact model of your "nVidia chipset". Some drivers behave vastly differently on different models.
• VSync sometimes causes stuttering issues. Try disabling all VSync options in your driver and compton.
• Just a confirmation: It doesn't happen with X Render backend? It doesn't happen without a compositor?
• Does it occur with other OpenGL compositors?
• Does switching WM help? (I know it shouldn't be related, but just in case.)
• Does dropping all compton configurations except --backend help? I.e., compton --config /dev/null --backend glx.
• Is it tied with a specific Xft font, or all Xft fonts?
• Does it occur in other applications running in your terminals with similar operations?
• Does it occur in other Xft applications that uses no other abstractions? conky probably is one of the them, but pay attention to its DBE support.
• Have you ever tried using an alternative driver? E.g. nouveau.
• Does changing driver configuration help? Specifically, NoAccel in xorg.conf.
• Does it have something to do with applications running in background? Try leaving no other windows on the desktop except the problematic one, including your task bars. The screen refresh interval may have something to do with the update of your other windows, and some OpenGL applications may disturb other applications when the driver isn't too sane.
• Compling compton with additional macros (-DDEBUG_GLX_PAINTREG and -DDEBUG_REPAINT) might reveal valuable debugging info, but they are moderately tricky to use.
• Does the stuttering happen with particular rules (e.g. fixed position, happening only after you do particular things) or randomly?
• Does moving the problematic window around change anything?
• Do you have a patched libXft (like, with infinality) or other related components? Are you using cutting-edge versions of those things?
• Does forcing compton to paint infinitely with --benchmark help?
• Disable "Allow Flipping" in nvidia-drivers, and run compton with --config /dev/null --backend glx --glx-swap-method copy may show the issue more clearly? Note "Allow flipping" has negative impact on performance.

[ghost]

First of all, thank you very much for your verbose support efforts!

• You're probably right, this issue seems to be nvidia-related since my tests with an ATI-chipset and (additionally) a VBox didn't show this problem. At the moment, I'm testing on a relatively old Intel, and afaics no problems, too.
• Anyway, Distro is Arch w/ nvidia 325.15 (nouveau doesn't work here) and compton 2013.10.01.g796e2c6
• Disabling everything w/ vsync (or compton himself respectively the glx-backend) actually resolves this problem, but due to the fact that I get i. a. massive tearing problems w/o vsync, this isn't a real solution.
• This is triggered by all xft-fonts I've tried (about 10 different ones). So I guess, it isn't font-specific but xft-related in general.
• Nope, doesn't happen w/ xrender neither w/o any compositor respectively not w/ any other compositor… Therefore, I tested urxvt and dmenu under KDE and GNOME (got btw. straight rid of the last one afterwards ;))
• Moving the window around doesn't help.
• Yes, every application that runs in the xft-terminal is affected and so is dmenu.And it isn't randomly at all, but fully reproducable at any time.
• No custom xft-patches here.
• The benchmark-flag doesn't seem too help.

To me, this issue looks like compton (or the driver or something else) just "forgets" for a few seconds to update the screen in the affected applications.

So this is just a status update; it might take me a few days to answer your other questions since I don't have that much time during the week and all this testing stuff takes quite a while…

[richardgv]

Your diagnostics went much further than what I expected, with my extremely brief and abstract instructions. :-D

Disabling everything w/ vsync (or compton himself respectively the glx-backend) actually resolves this problem, but due to the fact that I get i. a. massive tearing problems w/o vsync, this isn't a real solution.

If simply disabling VSync, without touching anything else, actually fixes the issue, it's almost certainly a problem of the driver. The core VSync function calls are only a few lines long, and it's almost impossible that we made a mistake in it. You may try different combinations of enabling/disabling driver VSync and compton VSync options (the various --vsync methods) to see if they bring any luck, but the issue really should be reported to nVidia right now.

By the way, you may use --vsync opengl with X Render backend. It doesn't perform as good as when under GLX backend, but might be sufficient for you.

Update: SlackBox reported X Render backend + --vsync opengl helps in #155.

This is triggered by all xft-fonts I've tried (about 10 different ones). So I guess, it isn't font-specific but xft-related in general.

Moving the window around doesn't help. ... The benchmark-flag doesn't seem too help. ... Yes, every application that runs in the xft-terminal is affected and so is dmenu.And it isn't randomly at all, but fully reproducable at any time. ... To me, this issue looks like compton (or the driver or something else) just "forgets" for a few seconds to update the screen in the affected applications.

--benchmark enforces compton to constantly repaint, as fast as it could. If you compile compton with CPPFLAGS='-DDEBUG_REPAINT', you could see the interval between repaints printed out. So I suppose it most likely isn't compton forgetting to update, but... Either some X/GLX calls compton sends freezes it, or X fails to deliver the correct window content, or X/GLX fails to update the screen when compton prompts it to.

When Xft struck updates of a window, are other windows around affected? Like, your conky window in the background.

Even though this is probably not a bug in compton, investigating with other compositors may help, to find... Perhaps workarounds or something.

[ghost]

Hey, these are the first rather good news today, thanks guys!

Xrender and just OpenGL (w/o any appendix) actually seem to work here, too (must have somehow missed that combo in my previous tests…)

So let me see if I got this right:

• The whole issue is now definitively nvidia-driver related since it's triggered by using the glx-backend and should be taken upstream, right?
• Jfmi: Do I have to set xrender manually or is this default anyway?
• In which sense does xrender perform more poorly than glx? Is there a common example to watch the expected performance-difference?

Besides, Conky doesn't seem to be affected and neither seem to be applications that use pango instead of xft.

[richardgv]

Xrender and just OpenGL (w/o any appendix) actually seem to work here, too (must have somehow missed that combo in my previous tests…) ... The whole issue is now definitively nvidia-driver related since it's triggered by using the glx-backend and should be taken upstream, right?

• It's good that it's working now. What did you mean by "just OpenGL"?
• I don't usually say "definitely" or "definitively". We can't completely exclude the possibility that certain things in compton triggered the issue, but most likely there is a problem in nvidia-drivers, at least, and it would be worthwhile to report this to nVidia.
• I would recommend you to get more specific results about which feature in compton or which combination of compton and driver settings causes the issue before you report to nVidia. Those people won't read compton's source code just for handling your problem.

Jfmi: Do I have to set xrender manually or is this default anyway?

The default, unless your distro installs a configuration file that states otherwise.

In which sense does xrender perform more poorly than glx? Is there a common example to watch the expected performance-difference?

• It isn't easy to spot the difference generally.
• X Render tends to use more CPU than GPU. Where this actually happens depends on the driver.
• X Render may perform very poorly with --blur-background or --invert-color-include.
• X Render may exhibit a longer/shorter flicker when the screen is redirected/unredirected? (--unredir-if-possible)
• X Render backend has fewer --vsync methods to choose, and those that works generally doesn't perform as good. (For example, you may see a smaller tearing line on the top of the screen.) It's (generally) not affected by VSync options in the driver.
• X Render always does incremental repaints while GLX backend do full-screen repaint by default (because that's how OpenGL works). This may give X Render some benefits in performance, but GLX backend has various fine-tune options (--glx-swap-method, --glx-use-copysubbuffermesas, --glx-copy-from-front) to do (partial) incremental updates.
• --benchmark frequently doesn't show correct FPS for X Render.

[ghost]

Sorry if I didn't express myself clearly enough concerning the "just opengl" thing (englisch isn't my native language, I never grew roughly fluent in it). I just ment that I used "opengl" for vsync an not "opengl-swc" or "opengl-oml" or something like that…

I will absolutely analyze explicitly which combinations work and which results in the issue described above before reporting this to nvidia; weekend's near, so there will be time for testing. :)

Anyway, thanks for your explanations regarding xrender which sound to me like: If there aren't any cruel performance issues and the CPU-load stays normal, you can use xrender without bad conscience. But what's about that "smaller tearing line on the top of the screen" you mentioned? I really can't image how this looks…

[richardgv]

Sorry if I didn't express myself clearly enough concerning the "just opengl" thing. I just ment that I used "opengl" for vsync an not "opengl-swc" or "opengl-oml" or something like that…

Oh... I see.

(englisch isn't my native language, I never grew roughly fluent in it)

Neither it is for me. :-)

But what's about that "smaller tearing line on the top of the screen" you mentioned? I really can't image how this looks…

They described the tearing on the top of the screen a lot in #7, before I introduced GLX backend and opengl-swc VSync:

... it's tears only on top of screen where my panel situated ... ... I say almost because I only have tearing at the very top of the screen. ... ... the tearing line is pinned to the top of my screen and during normal operation is completely invisible ... ... tearing is now fixed at ~150px from the top ...

[zsrkmyn]

thank you for your hard work to such an excellent compositor at first. but i still meet a small trouble when using it together with dmenu. i find it that compton always make the dmenu transparent as it does on other inactive windows. is there any way to solve it? my wm is herbstluftwm.

[richardgv]

@zsrkmyn:

--mark-wmwin-focused --mark-ovredir-focused might help.

[zsrkmyn]

@richardgv yes thx, it works with "--mark-ovredir-focused"!

[ghost]

Hey, thank you very very much for xr_glx_hybird! :+1: That actually seems to solve my nvidia caused problem!

But why is it spelt that way ("hybird" instead of "hybrid")? o.O

Anyway, I'll now run a couple of tests with various driver settings and see if the lagging comes back… But if it doesn''t, this ought to be a really happy christmas. :smile:

Once again: thanks for your great work, no matter if hybird actually is the fix for my problem or not!

JFYI: Meanwhile, I run a few tests w/ nouveau, but it turned out that this caused quite annoying stuttering by scrolling in vim/ranger/urxvt/… This is obviously caused by activating nouveau's GLXVBlank, which is necessary for any kind of vsync – w/o it, none of compton's vsync methods works.

[ghost]

Thanks, since I don't like branch-hopping that much: when is this going to hit the master branch?

[richardgv]

But why is it spelt that way ("hybird" instead of "hybrid")? o.O

Well, I can't believe I've been spelling it incorrectly for years... Thanks! :-)

JFYI: Meanwhile, I run a few tests w/ nouveau, but it turned out that this caused quite annoying stuttering by scrolling in vim/ranger/urxvt/… This is obviously caused by activating nouveau's GLXVBlank, which is necessary for any kind of vsync – w/o it, none of compton's vsync methods works.

Heh, that sucks, though probably it has something to do with your model.

Thanks, since I don't like branch-hopping that much: when is this going to hit the master branch?

In a few days, if I still remember this at the time. :-D

[ghost]

So it seems that the hybrid backend actually does the trick w/ nvidia & xft. :-D Just for clarification: When using the hybrid backend, I can/should/must specify all glx-options as well as all xrender-options in my .compton.conf, right? Does that mean that I can now use e. g. sw-opti and vsync=opengl at the same time, although the man page tells me not to do so?

I also think you should probably understand the hybrid backend not just as a tricky workaround for driver-caused problems, but as a real alternative to the two common backends. Why? Because my tests w/ hybrid shown a performance increase not only w/ nvidia, but also on an intel-driven machine, even though the glx backend worked there virtually perfect before; for example dragging windows around is muuuch smoother w/ hybrid than w/ glx and temperature seems to stay lower for about 1-2 degrees.

I literally don't know anything about the technical background of the different backends, but you once said that xrender tends to use more CPU and glx more GPU, so is it possible that hybrid causes some sort of "load balancing" between CPU and GPU? Would be a nice side-effect imho…

Merry Christmas.

[richardgv]

Just for clarification: When using the hybrid backend, I can/should/must specify all glx-options as well as all xrender-options in my .compton.conf, right?

Usually you can combine X Render and GLX options, but there's nothing absolute. Generally speaking, X Render options will affect all the window image blending while GLX options will affect the last step of rendering the blended image to root window or X composite overlay. --glx-no-rebind-pixmap might be important for you since rebinding pixmap is slow under nvidia-drivers, by the way.

Does that mean that I can now use e. g. sw-opti and vsync=opengl at the same time, although the man page tells me not to do so?

I guess it still sounds like a bad idea to combine those two options and it's unlikely to bring you much benefits (unless you set --refresh-rate to a very low value). Feel free to try, nonetheless.

I also think you should probably understand the hybrid backend not just as a tricky workaround for driver-caused problems, but as a real alternative to the two common backends. Why? Because my tests w/ hybrid shown a performance increase not only w/ nvidia, but also on an intel-driven machine, even though the glx backend worked there virtually perfect before; for example dragging windows around is muuuch smoother w/ hybrid than w/ glx and temperature seems to stay lower for about 1-2 degrees.

Thanks for telling me about it. :-) It's hard to say. GPU is typically vastly superior in graphic operations (if you follow its rules, of course), but the cost of utilizing it is not cheap (all those RAM <-> VRAM transfers, so many layers of abstractions, and probably some design issues in X) and the quality depends on the drivers. It becomes the prominent factor under light load (like compositing). Only through experiments could one tell which is faster on a specific system, and it's good if and only if it's suitable for you. :-)

I literally don't know anything about the technical background of the different backends, but you once said that xrender tends to use more CPU and glx more GPU, so is it possible that hybrid causes some sort of "load balancing" between CPU and GPU? Would be a nice side-effect imho…

Only the last paint in a frame uses OpenGL, which I suppose won't do much balancing but actually wastes some time rendering a Pixmap to window (instead of flipping the buffer directly). It may appear faster simply because X Render works very fast on your box. (And indeed, X Render is very fast with nvidia-drivers unless you try to use filters or weird logic ops, required for blurring and color inversion.) I made wrong assumptions about performance more than once, though.

Merry Christmas.

Merry Christmas. :-)

[supreme-gentleman]

I'm having the same issue with urxvt and compton but I can't install the drivers since I'm using a laptop I use for work and I run linux as a virtual machine and windows as a host...It's very painful for me because even vim and neovim are not working correctly and I really need to use that editor. I don't know what to do, sorry, I'm still a noob, could you help me with this issue? I can't install Nvidia drivers inside my virtual machine.

[sandsmark]

Interestingly enough I have the same issue now, but with intel, not nvidia. I'll see if I can reproduce it with repaint debugging stuff enabled.

[frangio]

I was having the same issue a week ago on Intel Video using the xf86-video-intel driver. There has been some discussion online lately surounding this driver as it is apparently bloated and buggy, and some people suggest falling back on the modesetting driver which is part of Xorg. I've been using this driver since and the issue has disappeared.

I should also probably add that the hybrid compton backend didn't work well on my laptop. It was very sluggish.

[richardgv]

Some quick tips that are not mentioned in the previous discussion:

• --xrender-sync --xrender-sync-fence is probably helpful for the situation. Note the latest stable version, 0.1_beta2, does not include the switches, and you need to build from the master / richardgv-dev branch to get it.
• GLX backend: If you have --glx-swap-method enabled, try disabling it. An incorrect value (or bug in its code) may leave out-dated contents in certain regions.
• GLX backend: If you have --glx-no-rebind-pixmap enabled, try disabling it. If your driver actually requires rebinding after window content changes, the optimization may cause compton to receive out-dated window contents. LLVMpipe and xf86-video-intel belong to the category.

If anybody still experiences the issue and the methods above do not help, please leave a comment with more detailed description of the hardware, drivers, and symptoms, and I will provide more instructions for diagnostics.

@frangio:

I should also probably add that the hybrid compton backend didn't work well on my laptop. It was very sluggish.

There are some synchronization issues in the backend: We probably failed to wait until X Render operations complete before starting GLX operations. I will unfortunately need more knowledge about the operation of X Render and OpenGL to fix it.

[sandsmark]

--xrender-sync and --xrender-sync-fence seems to have fixed it for me.

I had not enabled the two other options.

[arbitrary-dev]

--xrender-sync and --xrender-sync-fence

Hell yeah! Dat helps, thanks!

[Procrat]

--xrender-sync-fence also did the trick for me. Is this the recommended solution (for now)?

[tidux]

I have a command line that works well for me on Intel (Skylake) plus Nvidia bumblebee config:

compton -b --backend xr_glx_hybrid --vsync-use-glfinish --vsync drm --unredir-if-possible --paint-on-overlay

Performance is much snappier and I'm not seeing any of the redraw artifacts I was getting on the pure GLX backend.

[alecmev]

I have a Kaby Lake Intel, and the only thing that has worked for me was switching to DRI2. I'm using Compton with GLX backend, without vertical sync (I'm witnessing no tearing), with Intel drivers (modesetting driver didn't help, even though it's DRI2-only), on 4.10 kernel. Neither XRender nor the hybrid backend helped, nor did XSync (the --xrender-sync flags). Man, the graphical situation is frustrating on Linux...

EDIT Scratch that, XTerm issues came back after I fiddled with my monitor setup. What's currently working for me is disabling Compton altogether, and using these driver options instead:

Option "DRI" "2"
Option "TearFree" "true"