Open serin113 opened 9 years ago
I can sortof second this, under Awesome WM with Compton running, the entire chrome window does this every time after switching back from a different tag (or "workspace"). The whole browser window doesn't render (shows a ghost window of the previous workspace) but as different parts of the ui get re-rendered (like opening a menu or scrolling the page), those parts of the actual window come back into view, and the whole window re-renders when a tab is switched.
This only happens when using Compton and Chrome together (also have not tested in a different window manager)
I can confirm with ViktorNova. I have a distro called Chromixium and I am using Compton and Chromium browser. No effects, I just need Compton to get transparency in Plank dock. If you minimize Chromium and then restore, the entire window contents do not re-render and you can often see the desktop or a window beneath Chromium. F5/refresh sometimes fixes it. This is on Ubuntu 14.04.
changing the backend fixes it
backend = "xrender" # Backend to use: "xrender" or "glx".
Thanks samdraz, that fix appears to work. Just going to get some feedback from users to confirm...
this bugs appeared after upgrading xserver-xorg-video-intel from 2.21.15 to 2.99.917
Can confirm, samdraz's suggestion for changing the backend to "xrender" instead of "glx" does eliminate pretty much all the issues, so far.
So, I guess the problem's something about the GLX rendering in Compton?
I still experience the issue even while using the xrender backend.
I have xserver-xorg-video-intel version 2:2.99.910-0ubuntu1.6 installed, and I just cloned the latest version of compton, git-v0.1_beta2-68-gb1889c1-2015-04-20.
Yes, sorry I was too quick to say the fix worked. It worked under Virtualbox with the Vbox extensions running, but not on my Intel laptop. The fix is to upgrade to the latest Ubuntu LTS hardware enablement stack: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
So I think we can say that the bug is in xorg. Although it's strange that it only started with recent updates to Chromium Browser (39 onwards) and doesn't happen in any other application. It also doesn't tear under Unity or Gnome 3 (I haven't tested in XFCE or KDE). Something to keep an eye on, as Chromium could yet break xorg/compton again :(
Thanks for all your help guys!
The bug's probably something about Chrome's Aura compositor (if I'm not mistaken) conflicting with a certain version of Xorg (probably Ubuntu-specifc). This is most likely not a Compton-specific problem, but I'm not really sure.
The "xrender" fix did work for me, but that's probably because my version of xorg is different: xf86-video-intel 2.99.917-5 I'm using Arch Linux, if that helps.
Anyways, maybe this issue should be closed once it's proven that it isn't just Compton having this problem.
Uncheck in Chrome: Use hardware acceleration when available. This fixes it for glx too.
This was unchecked by default on my system (Ubuntu 14.04). Checking it didn't work. So far adding --backend glx --paint-on-overlay seems to work.
workaround , by disabling all of the glx driver OPTIONS since it causes popup to become invisible(except stencil),
#glx-copy-from-front = false; # Useful with --glx-swap-method,
# glx-use-copysubbuffermesa = true; # Recommended if it works. Breaks VSync.
#glx-no-rebind-pixmap = true; # Recommended if it works.
#glx-swap-method = "undefined"; # See man page.
People use exactly compton + glx for tear-free compositing on XFCE or LXDE. It makes no sense to switch it off.
Reproduced on compton from git version (08/10) f1cd308cde0f1e1f21ec2ac8f16a3c873fa22d3a
and intel xorg driver built from sources with version (08/12) c8fc7f5e4bdd5b1e3212a226a2873393b5745f14
.
I failed to reproduce the issue with xorg-server-1.18.4, nvidia-drivers-370.23, chromium-53.0.2785.34 (with default hardware acceleration settings), and a compton build at f1cd308 (latest right now), on fvwm-2.6.5 and awesome-3.5.9. I tried using compton.sample.conf
+ --backend=glx
and no configuration file + --backend=glx --paint-on-overlay
. I saw nothing wrong after a while of browsing, repeatedly opening various menus, minimizing and restoring the main window, and switching between virtual desktops.
Some initial steps to diagnose the issue:
glx
or xr_glx_hybrid
backend, try disabling all GLX optimization options, as @smdrz suggested. Specifically:
--glx-no-rebind-pixmap
is known to be broken with various drivers, notiably LLVMpipe and xf86-video-intel.--glx-swap-method
could generate breakages if it does not match the actual buffer swap method.--xrender-sync --xrender-sync-fence
helps. It fixes the problem that compton fails to receive up-to-date window contents in some cases.Check if anything changes if you launch compton with the following commands:
compton --config /dev/null --backend=xrender --paint-on-overlay --xrender-sync --xrender-sync-fence
compton --config /dev/null --backend=glx --paint-on-overlay --xrender-sync --xrender-sync-fence
I have experienced this issue on xf86-video-intel 1:2.99.917+668+gc28e62f-1
.
glx-no-rebind-pixmap = false
fixed this issue for me.
Same problem here, fixed using :
backend = "glx";
glx-no-rebind-pixmap = false;
Sorry to necrobump - having this issue on compton from debian stretch (0.1~beta2+20150922), with popup windows in Firefox (60.4.0) using the glx backend
Trying @richardgv 's tests, I now have this log, after opening such a popup window:
$ compton --config /dev/null --backend=glx --paint-on-overlay --xrender-sync --xrender-sync-fence
glx_update_fbconfig(): No FBConfig found for depth 32. Expect crazy things.
glx_bind_pixmap(32): Couldn't find FBConfig with requested depth.
win_paint_win(0x00a05aaf): Failed to bind texture. Expect troubles.
win_paint_win(0x00a05aaf): Missing painting data. This is a bad sign.
[many, many repeats]
None of the advice above helps unless I turn off the glx backend, which kills performance and reintroduces bad tearing.
ETA: Fixed by removing all of my opacity-rules. Just like the man page says:
Note we do not distinguish 100% and unset, and we don’t make any guarantee about possible conflicts with other programs that set _NET_WM_WINDOW_OPACITY on frame or client windows.
Compton v7.5
Setting fading = false;
solved the problem for me.
Edit: I am using GLX backend
Just came here to say none of the above worked for me, even maximizing windows & switching workspaces caused issues. Since the issue started in 2015, it might be a series of different issues..which all revolve around the chromium-codebase (not compton). A solution which did work for me:
chromium-browser %U
to chromium-browser %U --disable-gpu-compositor
)Just try launching it with that flag and see whether it solves the issue.
NOTE: just wanted to say big thanks for all compton maintainers, you did an awesome job in making the linux desktop beautiful, thank you very much.
Basically, popup menus invoked by a right-click on a webpage may sometimes not show up... until the area where it should appear is hovered on by the cursor. Each item in the menu individually shows up only when hovered on.
Here's a screencap of the issue, with some more details: https://www.youtube.com/watch?v=VG1q6LnAB3M
Also tried the exclude options against Chromium listed there on fade-exclude, focus-exclude, and blur-background-exclude, to no avail. Also tried completely disabling fading and shadows, issue still occurs.
I'm honestly not sure if it really is a Compton issue, but it does only show up when Compton's running; other compositors don't show this.
I don't really know how to gather debug info on the right-click popup menus that immediately disappear upon losing focus, sorry >.<