yshui / picom

A lightweight compositor for X11 with animation support
https://picom.app/
Other
4.1k stars 586 forks source link

Backround Wallpaper flickers when changing windows between workspaces #16

Open wooque opened 5 years ago

wooque commented 5 years ago

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

  1. Enable smart_borders in i3 (or disable borders all together), so there is no borders when single app in workspace is open
  2. Open Chromium as only app in workspace
  3. Open any other app in other worspace
  4. Switch between workspaces

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?

yshui commented 5 years ago

Can you try setting unredir-if-possible to false?

wooque commented 5 years ago

Yeah, I already tried that, same.

yshui commented 5 years ago

@wooque OK, just want to be 100% sure. Can you run compton --config /dev/null --backend glx, and see if it still happens?

wooque commented 5 years ago

@yshui yes, it still happens

yshui commented 5 years ago

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.

wooque commented 5 years ago

@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

wooque commented 5 years ago

Also I noticed the same in the past when switching workplaces in XFCE

yshui commented 5 years ago

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.

wooque commented 5 years ago

default_border pixel 1, will get rid of titlebar.

yshui commented 5 years ago

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 commented 5 years ago

Without fading https://drive.google.com/file/d/1uc-RODLyVdi2jBpsOQMStsODDncG-yJe/view With fading https://drive.google.com/file/d/1K6sshHi36FK9t7uc5HJhqjvz5_RRLFbT/view

yshui commented 5 years ago

@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.

kchibisov commented 5 years ago

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:

GPUs:
mustaqimM commented 5 years ago

@kchibisov I have border width set to 1(on awesomewm) and when changed to 10, the flicker is less noticeable but still present.

yochaigal commented 4 years ago

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.

daankata commented 4 years ago

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. simplescreenrecorder-2020-05-26

nikolaevigor commented 3 years ago

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.

daankata commented 3 years ago

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.

nongthaihoang commented 3 years ago

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.

gbaranski commented 3 years ago

It is much better with --experimental-backends, but still not perfect, sometimes while switching workspaces i can see background

gbaranski commented 3 years ago

Turns out it's problem caused by i3, issues are gone after switching to dwm that was just for first few minutes, later it started again to flicker

ExternalCombustionEngine commented 3 years ago

Also experiencing this.

bspwm 0.9.10 picom v8.2 (glx backend) Void Linux

gbaranski commented 3 years ago

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

ExternalCombustionEngine commented 3 years ago

solution: switch to Wayland and say goodbye to tearing, flickering, high latency

This is utterly irrelevant to the entirety of picom.

victorbnl commented 2 years ago

I have the same issue. Is there some sort of workaround or a fork that fix it yet?

ncfavier commented 2 years ago

Workaround is a few comments up: https://github.com/yshui/picom/issues/16#issuecomment-792739119

victorbnl commented 2 years ago

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!

ncfavier commented 2 years ago

30 ms works well for me with no noticeable fading.

victorbnl commented 2 years ago

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.

mxmilkiib commented 2 years ago

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.

https://i.imgur.com/2E9QTNv.mp4

yaaama commented 5 months ago

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.

ArijanJ commented 2 weeks ago

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