Open wooque opened 5 years ago
Can you try setting unredir-if-possible
to false?
Yeah, I already tried that, same.
@wooque OK, just want to be 100% sure. Can you run compton --config /dev/null --backend glx
, and see if it still happens?
@yshui yes, it still happens
I tried to reproduce this under i3-gaps but failed.
I'm using i3-gaps with a status bar and title bars on top of windows. chromium is the only window open in workspace. And I didn't notice any flashing.
@yshui I have disabled titlebars and borders if there is only one app in workspace, so app fills whole screen except status bar which is on top. Relevant i3 config
bar {
position top
}
default_border pixel 1
smart_borders on
Try this
Also I noticed the same in the past when switching workplaces in XFCE
I have tried setting the chromium window fullscreen, and didn't notice the flash.
I have smart_borders on
, but chromium still have a title bar when it's the only window.
default_border pixel 1, will get rid of titlebar.
OK. Now there is no title bar, status bar is on top. Still can't reproduce the flashing.
Or maybe I don't know what to look for. Could you record a video of the flashing?
@wooque I see. However this is somewhat unavoidable. Performance improvements might make this less obvious, though.
Also, the xrender backend might work a little bit better.
Hi, @yshui, I am experiencing the same issue with window flickering. The problem is somehow related to border width. if the window border width is set to 0 the flickering start happening ( tested in i3, bpswm, awesomewm). This is true even for fullscreen windows with unredir-if-possible = false;
, but if you somehow altered the fullscreen window border size to something different then 0, flickering will disappear (tested in bspwm).
One important thing, that I've noticed that there wasn't any flickering with glx experimental backend until 8dc250a415b2ad6f6dfe4b9d19f99fb223202152 . However It was segfaulting if you start switching windows very fast. But after this commit even slow window switching will cause flicker ( They occurs from time to time if your border width is set to 0 ofc. (e.g. fullscreen windows )).
Systems used for testing this:
@kchibisov I have border width set to 1(on awesomewm) and when changed to 10, the flicker is less noticeable but still present.
Has anyone resolved this issue with compton or picom? I'm experiencing flickering when changing workspaces on fullscreen windows only; see here: https://i.imgur.com/5i7Nkwp.mp4
Also see sister issue on deprecated compton repo.
It looks that the background flickering happens when switching between workspaces. Also, the higher the 'fade-delta' setting (e.g. >20), the more evidently it shows the background wallpaper. This doesn't seem to be a performance issue.
I recorded a gif in which I switch between workspace-1 and workspace-2 in i3 with Firefox opened in both workspaces. As I am using feh to manage my desktop background it appears that picom first loads feh and then it opens Firefox thus creating a background wallpaper flickering when 'fade-delta' is set lower?
The gif has some minor side tearing because of my capture software.
I am experiencing this issue too.
Environment
i3 version 4.18.2 (2020-07-26)
picom (built from next
, to use dual_kawase
blur, glx backend)
Arch Linux
For example if I have two instances of Chrome in one workspace (workspace in tab mode) and I switch between them, it filckers with walllpaper. I can not reproduce it several times in a row, so it take some time to spend on one tab (i3 tab, not Chrome) and then switch to another to ovserve it. It also appears when switching between workspaces, with same frequency.
I am not sure how yet, but I think a workaround for the problem would be by excluding the background desktop with the fade-exclude
setting in picom. This way when changing between workspaces it won't fade the desktop wallpaper every time and it will just load the applications on top? As I said this is only a workaround and not a fix, as fixing the problem would probably be for the composite manager to first load the top focused applications and then the back ones so it doesn't produce this flickering effect.
I'm using picom only for vsync, no fading, I prefer everthing appear instantly. I had the same background flashing problem no matter what I set the fading on or off. After reading a lot on google. I somehow fixed the issue (at least it works for me). So I post my solution here in case someone may find it useful. This is what I did:
fading = true
fade-in-step = 1
fade-out-step = 1
fade-delta = 50
Despite setting the fading = true
, but the fade-in/out-step = 1
means no fading at all. Here, the point is the fade-delta = 50
. I think when switching to another workspace, picom shows the background first and then app windows. It simply tells picom to not show any thing before the first 50 ms and the result is the background wasn't showd up.
It is much better with --experimental-backends
, but still not perfect, sometimes while switching workspaces i can see background
Turns out it's problem caused by that was just for first few minutes, later it started again to flickeri3
, issues are gone after switching to dwm
Also experiencing this.
bspwm 0.9.10 picom v8.2 (glx backend) Void Linux
Also experiencing this.
bspwm 0.9.10 picom v8.2 (glx backend) Void Linux
solution: switch to Wayland and say goodbye to tearing, flickering, high latency
solution: switch to Wayland and say goodbye to tearing, flickering, high latency
This is utterly irrelevant to the entirety of picom.
I have the same issue. Is there some sort of workaround or a fork that fix it yet?
Workaround is a few comments up: https://github.com/yshui/picom/issues/16#issuecomment-792739119
Oh right I didn't see it! It's not perfect as it seems to make a transition a bit slower and almost gives the impression of a fast fading but it does work pretty well, thanks!
30 ms works well for me with no noticeable fading.
It does for me too, but I do notice a very little bit of fading though. But I'm just nitpicking anyway x). I can't wait for picom to be fixed with this properly though.
I think I've got is the same issue; switching between any two windows or desktops/workspaces (so not just workspaces; this point isn't made above) under AwesomeWM gives a very brief fade in (no very brief fade out). The workaround above doesn't resolve the issue for me, nor does setting those fade options to 0 or 1, switching backend to glx or adding the arg --experimental-backends. I've started from the sample conf and disabled a few things, as I'm only looking to have borders on unactive windows transparent ('useful gaps'). Unfortunatly this fade flash hurts my head too much to use picom.
This is still occuring with the latest version.
The workaround that @nongthaihoang used is helping the situation but if I switch workspaces on BSPWM too quickly (especially when it contains Chromium in fullscreen), then the background flashes again.
I fixed this by setting use-damage = false
in my picom.conf, but there may be side effects which you may mind (Potentially degrades the performance
).
Edit: actually doesn't completely fix it after some further testing, but it definitely happens less often
Platform
Arch Linux amd64 i3-gaps 4.15
GPU, drivers, and screen setup
Intel HD Graphics 5500 mode-setting driver, but it's the same with xf86-video-intel one 1920x1080 monitor
Compton version
v2.0
Compton configuration:
Default one that comes with Arch except no-fading-openclose = true
backend = "glx"; glx-no-stencil = true; glx-copy-from-front = false; glx-swap-method = "undefined"; shadow = true; no-dnd-shadow = true; no-dock-shadow = true; clear-shadow = true; shadow-radius = 5; shadow-offset-x = -5; shadow-offset-y = -5; shadow-opacity = 0.5; shadow-exclude = [ "! name~=''", "name = 'Notification'", "name = 'Plank'", "name = 'Docky'", "name = 'Kupfer'", "name = 'xfce4-notifyd'", "name = 'VLC'", "name = 'compton'", "name = 'Chromium'", "name = 'Chrome'", "class_g = 'Conky'", "class_g = 'Kupfer'", "class_g = 'Synapse'", "class_g ?= 'Notify-osd'", "class_g ?= 'Cairo-dock'", "class_g ?= 'Xfce4-notifyd'", "class_g ?= 'Xfce4-power-manager'", "_GTK_FRAME_EXTENTS@:c" ]; shadow-ignore-shaped = false;
menu-opacity = 1; inactive-opacity = 1; active-opacity = 1; frame-opacity = 1; inactive-opacity-override = false; alpha-step = 0.06;
blur-background-fixed = false; blur-background-exclude = [ "window_type = 'dock'", "window_type = 'desktop'" ];
fading = true; fade-delta = 4; fade-in-step = 0.03; fade-out-step = 0.03; no-fading-openclose = true;
fade-exclude = [ ]; mark-wmwin-focused = true; mark-ovredir-focused = true; use-ewmh-active-win = true; detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 0;
vsync = "opengl-swc"; dbe = false; paint-on-overlay = true; sw-opti = true; unredir-if-possible = true; focus-exclude = [ ]; detect-transient = true; detect-client-leader = true;
wintypes: { tooltip = { fade = true; shadow = false; opacity = 0.85; focus = true; }; };
Steps of reproduction
Expected behavior
No artifacts
Current Behavior
Background flashes for a bit when switching to Chromium, sometimes is more, sometime is less noticable, but if you switch back and forth you will notice
Other details
It doesn't happen with compton disabled, or I can't notice it. Also it does not happen when there are even 1px border around window. Disabling hardware acceleration in Chromium also seems to solve it.
It's very strage that 1px border solves it, what's the difference?, can I simulate same rendering for borderless windows without having to add border?