yshui / picom

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

When Mozilla Thunderbird is running, moving windows starts to lag #863

Closed Monsterovich closed 1 year ago

Monsterovich commented 2 years ago

This problem appears randomly, so I can't figure out what's causing it. The same thing seems to happen when Firefox is open, but less often.

Platform

Linux Mint 20.3

GPU, drivers, and screen setup

Graphics:
  Device-1: NVIDIA driver: nvidia v: 470.129.06 
  Display: x11 server: X.Org 1.20.13 driver: nvidia tty: N/A 
  OpenGL: renderer: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2 
  v: 4.6.0 NVIDIA 470.129.06

Environment

xfce4

picom version

vgit-cd505

Configuration:

Configuration file ``` ################################# # Shadows # ################################# # Enabled client-side shadows on windows. Note desktop windows # (windows with '_NET_WM_WINDOW_TYPE_DESKTOP') never get shadow, # unless explicitly requested using the wintypes option. # # shadow = false shadow = true; full-shadow = true; # The blur radius for shadows, in pixels. (defaults to 12) # shadow-radius = 12 shadow-radius = 7; # The opacity of shadows. (0.0 - 1.0, defaults to 0.75) # shadow-opacity = .75 # The left offset for shadows, in pixels. (defaults to -15) # shadow-offset-x = -15 shadow-offset-x = -7; # The top offset for shadows, in pixels. (defaults to -15) # shadow-offset-y = -15 shadow-offset-y = -7; # Red color value of shadow (0.0 - 1.0, defaults to 0). # shadow-red = 0 # Green color value of shadow (0.0 - 1.0, defaults to 0). # shadow-green = 0 # Blue color value of shadow (0.0 - 1.0, defaults to 0). # shadow-blue = 0 # Hex string color value of shadow (#000000 - #FFFFFF, defaults to #000000). This option will override options set shadow-(red/green/blue) # shadow-color = "#000000" # Specify a list of conditions of windows that should have no shadow. # # examples: # shadow-exclude = "n:e:Notification"; # # shadow-exclude = [] shadow-exclude = [ "! name~=''", "_GTK_FRAME_EXTENTS@:c", "override_redirect = 1 && !WM_CLASS@:s", "_NET_WM_STATE@[0]:a = '_NET_WM_STATE@_MAXIMIZED_VERT'", "_NET_WM_STATE@[0]:a = '_NET_WM_STATE@_MAXIMIZED_HORZ'", "name = 'Notification'", "name = 'plank'", "name = 'Docky'", "name = 'Kupfer'", "name = 'xfce4-screenshooter'", "name = 'xfce4-display-settings'", "name *= 'xfwm4'", "name *= 'VLC'", "name *= 'compton'", "name *= 'VirtualBox'", # "name *= 'Chromium'", # "name *= 'Chrome'", "(name *= 'Firefox' || name *= 'Thunderbird') && (window_type = 'utility' || window_type = 'popup_menu') && argb", "_NET_WM_WINDOW_TYPE:a *= '_KDE_NET_WM_WINDOW_TYPE_OVERRIDE'", # Telegram "name *= 'LibreOffice'", "name *= 'Wine'", "name *= 'SplashScreen'", "class_g = 'Kupfer'", "class_g = 'Synapse'", "class_g ?= 'Notify-osd'", "class_g ?= 'Cairo-dock'", "class_g ?= 'Xfce4-notifyd'", "class_g ?= 'conky'", "class_g ?= 'Xfce4-power-manager'" ]; # Specify a X geometry that describes the region in which shadow should not # be painted in, such as a dock window region. Use # shadow-exclude-reg = "x10+0+0" # for example, if the 10 pixels on the bottom of the screen should not have shadows painted on. # # shadow-exclude-reg = "" # Crop shadow of a window fully on a particular Xinerama screen to the screen. # xinerama-shadow-crop = false ################################# # Fading # ################################# # Fade windows in/out when opening/closing and when opacity changes, # unless no-fading-openclose is used. # fading = false fading = false; # Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028) # fade-in-step = 0.028 fade-in-step = 0.06; # Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03) # fade-out-step = 0.03 fade-out-step = 0.06; # The time between steps in fade step, in milliseconds. (> 0, defaults to 10) # fade-delta = 10 # Specify a list of conditions of windows that should not be faded. # fade-exclude = [] # Do not fade on window open/close. # no-fading-openclose = false # Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc. # no-fading-destroyed-argb = false ################################# # Transparency / Opacity # ################################# # Opacity of inactive windows. (0.1 - 1.0, defaults to 1.0) # inactive-opacity = 1 # inactive-opacity = 0.8; # Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default) # frame-opacity = 1.0 # frame-opacity = 0.7; # Let inactive opacity set by -i override the '_NET_WM_OPACITY' values of windows. # inactive-opacity-override = true inactive-opacity-override = false; # Default opacity for active windows. (0.0 - 1.0, defaults to 1.0) # active-opacity = 1.0 # Dim inactive windows. (0.0 - 1.0, defaults to 0.0) # inactive-dim = 0.0 # Specify a list of conditions of windows that should always be considered focused. # focus-exclude = [] focus-exclude = [ "class_g = 'Cairo-clock'" ]; # Use fixed inactive dim value, instead of adjusting according to window opacity. # inactive-dim-fixed = 1.0 # Specify a list of opacity rules, in the format `PERCENT:PATTERN`, # like `50:name *= "Firefox"`. picom-trans is recommended over this. # Note we don't make any guarantee about possible conflicts with other # programs that set '_NET_WM_WINDOW_OPACITY' on frame or client windows. # example: # opacity-rule = [ "80:class_g = 'URxvt'" ]; # # opacity-rule = [] ################################# # Corners # ################################# # Sets the radius of rounded window corners. When > 0, the compositor will # round the corners of windows. Does not interact well with # `transparent-clipping`. corner-radius = 0 # Exclude conditions for rounded corners. rounded-corners-exclude = [ "window_type = 'dock'", "window_type = 'desktop'" ]; ################################# # Background-Blurring # ################################# # Parameters for background blurring, see the *BLUR* section for more information. # blur-method = # blur-size = 12 # # blur-deviation = false blur-strength = 5 # blur-method = ""; # Blur background of semi-transparent / ARGB windows. # Bad in performance, with driver-dependent behavior. # The name of the switch may change without prior notifications. # #blur-background = true # Blur background of windows when the window frame is not opaque. # Implies: # blur-background # Bad in performance, with driver-dependent behavior. The name may change. # blur-background-frame = true # Use fixed blur strength rather than adjusting according to window opacity. # blur-background-fixed = true # Specify the blur convolution kernel, with the following format: # example: # blur-kern = "5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1"; # # blur-kern = "" blur-kern = "3x3box"; # Exclude conditions for background blur. # blur-background-exclude = [] blur-background-exclude = [ "_GTK_FRAME_EXTENTS@:c", "window_type = 'dock'", "window_type = 'desktop'", "name *= 'xfce4-notifyd'", "name *= 'xfce4-screenshooter'", "name *= 'xfwm4'", "name *= 'VirtualBox'", "name *= 'rect-overlay'", # Microsoft Teams (electron) "(name *= 'Firefox' || name *= 'Thunderbird') && (window_type = 'utility' || window_type = 'popup_menu') && argb", "window_type = 'tooltip'", "name *= 'Wine'", "class_g ?= 'conky'", "name *= 'SplashScreen'", "name *= 'compton'" ]; ################################# # General Settings # ################################# # Daemonize process. Fork to background after initialization. Causes issues with certain (badly-written) drivers. daemon = false # Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`. # `xrender` is the default one. # # backend = "glx" backend = "glx"; # Enable/disable VSync. # vsync = false vsync = true; # Enable remote control via D-Bus. See the *D-BUS API* section below for more details. # dbus = false # Try to detect WM windows (a non-override-redirect window with no # child that has 'WM_STATE') and mark them as active. # # mark-wmwin-focused = false mark-wmwin-focused = true; # Mark override-redirect windows that doesn't have a child window with 'WM_STATE' focused. # mark-ovredir-focused = false mark-ovredir-focused = true; # Try to detect windows with rounded corners and don't consider them # shaped windows. The accuracy is not very high, unfortunately. # # detect-rounded-corners = false detect-rounded-corners = true; # Detect '_NET_WM_OPACITY' on client windows, useful for window managers # not passing '_NET_WM_OPACITY' of client windows to frame windows. # # detect-client-opacity = false detect-client-opacity = true; # Use EWMH '_NET_ACTIVE_WINDOW' to determine currently focused window, # rather than listening to 'FocusIn'/'FocusOut' event. Might have more accuracy, # provided that the WM supports it. # # use-ewmh-active-win = false # Unredirect all windows if a full-screen opaque window is detected, # to maximize performance for full-screen windows. Known to cause flickering # when redirecting/unredirecting windows. # unredir-if-possible = true # Delay before unredirecting the window, in milliseconds. Defaults to 0. # unredir-if-possible-delay = 0 # Conditions of windows that shouldn't be considered full-screen for unredirecting screen. unredir-if-possible-exclude = [ "name *= 'mpv'" ]; # Use 'WM_TRANSIENT_FOR' to group windows, and consider windows # in the same group focused at the same time. # # detect-transient = false detect-transient = true; # Use 'WM_CLIENT_LEADER' to group windows, and consider windows in the same # group focused at the same time. 'WM_TRANSIENT_FOR' has higher priority if # detect-transient is enabled, too. # # detect-client-leader = false detect-client-leader = true; # Resize damaged region by a specific number of pixels. # A positive value enlarges it while a negative one shrinks it. # If the value is positive, those additional pixels will not be actually painted # to screen, only used in blur calculation, and such. (Due to technical limitations, # with use-damage, those pixels will still be incorrectly painted to screen.) # Primarily used to fix the line corruption issues of blur, # in which case you should use the blur radius value here # (e.g. with a 3x3 kernel, you should use `--resize-damage 1`, # with a 5x5 one you use `--resize-damage 2`, and so on). # May or may not work with *--glx-no-stencil*. Shrinking doesn't function correctly. # # resize-damage = 1 # Specify a list of conditions of windows that should be painted with inverted color. # Resource-hogging, and is not well tested. # # invert-color-include = [] # GLX backend: Avoid using stencil buffer, useful if you don't have a stencil buffer. # Might cause incorrect opacity when rendering transparent content (but never # practically happened) and may not work with blur-background. # My tests show a 15% performance boost. Recommended. # glx-no-stencil = false # GLX backend: Avoid rebinding pixmap on window damage. # Probably could improve performance on rapid window content changes, # but is known to break things on some drivers (LLVMpipe, xf86-video-intel, etc.). # Recommended if it works. # # glx-no-rebind-pixmap = false # Disable the use of damage information. # This cause the whole screen to be redrawn everytime, instead of the part of the screen # has actually changed. Potentially degrades the performance, but might fix some artifacts. # The opposing option is use-damage # # no-use-damage = false use-damage = true; # Use X Sync fence to sync clients' draw calls, to make sure all draw # calls are finished before picom starts drawing. Needed on nvidia-drivers # with GLX backend for some users. # # xrender-sync-fence = false # GLX backend: Use specified GLSL fragment shader for rendering window contents. # See `compton-default-fshader-win.glsl` and `compton-fake-transparency-fshader-win.glsl` # in the source tree for examples. # # glx-fshader-win = "" # Force all windows to be painted with blending. Useful if you # have a glx-fshader-win that could turn opaque pixels transparent. # # force-win-blend = false # Do not use EWMH to detect fullscreen windows. # Reverts to checking if a window is fullscreen based only on its size and coordinates. # # no-ewmh-fullscreen = false # Dimming bright windows so their brightness doesn't exceed this set value. # Brightness of a window is estimated by averaging all pixels in the window, # so this could comes with a performance hit. # Setting this to 1.0 disables this behaviour. Requires --use-damage to be disabled. (default: 1.0) # # max-brightness = 1.0 # Make transparent windows clip other windows like non-transparent windows do, # instead of blending on top of them. # # transparent-clipping = false # Set the log level. Possible values are: # "trace", "debug", "info", "warn", "error" # in increasing level of importance. Case doesn't matter. # If using the "TRACE" log level, it's better to log into a file # using *--log-file*, since it can generate a huge stream of logs. # # log-level = "debug" log-level = "warn"; # Set the log file. # If *--log-file* is never specified, logs will be written to stderr. # Otherwise, logs will to written to the given file, though some of the early # logs might still be written to the stderr. # When setting this option from the config file, it is recommended to use an absolute path. # # log-file = "/path/to/your/log/file" # Show all X errors (for debugging) # show-all-xerrors = false # Write process ID to a file. # write-pid-path = "/path/to/your/log/file" # Window type settings # # 'WINDOW_TYPE' is one of the 15 window types defined in EWMH standard: # "unknown", "desktop", "dock", "toolbar", "menu", "utility", # "splash", "dialog", "normal", "dropdown_menu", "popup_menu", # "tooltip", "notification", "combo", and "dnd". # # Following per window-type options are available: :: # # fade, shadow::: # Controls window-type-specific shadow and fade settings. # # opacity::: # Controls default opacity of the window type. # # focus::: # Controls whether the window of this type is to be always considered focused. # (By default, all window types except "normal" and "dialog" has this on.) # # full-shadow::: # Controls whether shadow is drawn under the parts of the window that you # normally won't be able to see. Useful when the window has parts of it # transparent, and you want shadows in those areas. # # redir-ignore::: # Controls whether this type of windows should cause screen to become # redirected again after been unredirected. If you have unredir-if-possible # set, and doesn't want certain window to cause unnecessary screen redirection, # you can set this to `true`. # wintypes: { tooltip = { # fade: Fade the particular type of windows. fade = true; # shadow: Give those windows shadow shadow = false; # opacity: Default opacity for the type of windows. opacity = 0.85; # focus: Whether to always consider windows of this type focused. focus = true; }; }; ```
Video https://user-images.githubusercontent.com/3750982/181473780-dc9c6024-8ff4-4294-b687-daaeb3c73e0b.mp4
Utagai commented 2 years ago

I'm amazed that someone noticed this too. I've always had issues with laggy window dragging and could never figure out why it was happening. Today I just realized that on a fresh boot, I don't have the problem until I start up Thunderbird. I also managed to get the problem to go away after a bad configuration change that stopped picom from running, and then restarting it.

This has to be a bug, the behavior makes no sense.

One thing I'd like to mention is that when this lagginess happens, if you use a refresh rate tester website, like this one, and drag the window, you'll notice the frame rate dips.

When you don't have this lagginess problem, the frame rate stays matched to your refresh rate. In my case, I have a 144 hz monitor, so the FPS stays at 144, and otherwise dips to anywhere between 70-90 while dragging. I don't know how picom works under-the-hood, but presumably it has a render loop -- this imply a slow-down there?

Monsterovich commented 2 years ago

@yshui What do you think might be causing this?

yshui commented 2 years ago

Not sure. Does picom use more CPU while you move a window?

Utagai commented 2 years ago

@yshui Great question, but no. It was one of the first things I looked into. My method of testing this was notably 'low-tech' though, I just spun up htop and kept an eyeball on it. Nothing major.

yshui commented 2 years ago

Do you also have a NVIDIA card?

Monsterovich commented 2 years ago

I did a little research when moving the window started to lag. I'm not sure, but it seems to me that picom is somehow slowing down the X server, maybe I'm mistaken.

https://user-images.githubusercontent.com/3750982/191718232-7c2c9997-766c-4661-83fc-e6e0adbfe8d2.mp4

However, when I closed thunderbird, the lags disappeared. The situation is the same if I just turn off the compositor.

yshui commented 2 years ago

I wonder if disabling sync fence would help.

Make sure you don't have xrender-sync-fence enabled in config file, then comment out this line and rebuild: https://github.com/yshui/picom/blob/fd381dacff5c755b43effba441fb5706a0f378a4/src/backend/driver.c#L20

Utagai commented 2 years ago

@yshui I can't comment for @Monsterovich but I personally do have a Nvidia card. GFX 2070 Super.

I can confirm that what I saw in CPU usage is similar to what @Monsterovich is showing in their demo. Slight increases in CPU when dragging, but nothing immense. I didn't think much of it, dragging windows was something I figured wasn't trivially cheap.

I can't quite yet test out the suggestion you just mentioned at the moment, but I should be able to do it later.

Monsterovich commented 1 year ago

I wonder if disabling sync fence would help.

Make sure you don't have xrender-sync-fence enabled in config file, then comment out this line and rebuild:

https://github.com/yshui/picom/blob/fd381dacff5c755b43effba441fb5706a0f378a4/src/backend/driver.c#L20

Disabling the parameter in the code, broke the update time of the widget, is this normal?

I also have some problems with rendering without this parameter. The problems are similar to screen tearing.

yshui commented 1 year ago

@Monsterovich

Disabling the parameter in the code, broke the update time of the widget, is this normal?

But does it fix the lag?

Monsterovich commented 1 year ago

@Monsterovich

Disabling the parameter in the code, broke the update time of the widget, is this normal?

But does it fix the lag?

Let me see another day or two, if nothing happens, it means that disabling the parameter fixed the lags.

yshui commented 1 year ago

wait! :sweat_smile:

this is for investigation, not a solution! I wonder if sync fence collectively took too long, of if it's just one sync fence that took absurdly long to complete. if you can, can you measure how long does x_fence_sync took to complete?

Monsterovich commented 1 year ago

wait! sweat_smile

this is for investigation, not a solution! I wonder if sync fence collectively took too long, of if it's just one sync fence that took absurdly long to complete. if you can, can you measure how long does x_fence_sync took to complete?

How can I do this?

I think the lags are gone.

yshui commented 1 year ago

@Monsterovich so get current time before and after the call and print the difference. i can quickly do that and give you a branch.

yshui commented 1 year ago

@Monsterovich it's the issue863-test branch. it should continuously print lines like this:

[ 09/26/2022 10:52:34.915 x_fence_sync WARN ] x_fence_sync: 0.000041 ms
[ 09/26/2022 10:52:34.943 x_fence_sync WARN ] x_fence_sync: 0.000028 ms
[ 09/26/2022 10:52:34.960 x_fence_sync WARN ] x_fence_sync: 0.000031 ms
[ 09/26/2022 10:52:34.976 x_fence_sync WARN ] x_fence_sync: 0.000028 ms
Monsterovich commented 1 year ago

@yshui I finally managed to catch the lags. Usually the time for x_fence_sync takes less than 0.001 ms, but when you move the window, the time to execute the function increases significantly (0.01 ms and greater).

https://user-images.githubusercontent.com/3750982/192600946-ffdf6d11-4cd9-4e46-9bfe-2dd6ef269d6d.mp4

yshui commented 1 year ago

@Monsterovich is this with thunderbird running? i didn't see the kind of lag you had in your original report.

Monsterovich commented 1 year ago

@Monsterovich is this with thunderbird running? i didn't see the kind of lag you had in your original report.

The lags appear spontaneously, but moving the window definitely lagged, and yes, thunderbird was running.

Monsterovich commented 1 year ago

Maybe not on the video, but the lags are very noticeable on the 144hz screen and over time the lags only get worse.

yshui commented 1 year ago

@Utagai What's you driver version?

Tokariew commented 1 year ago

I would say, that graphic happen whenever something using "gpu more heavily". For me it's most noticeable when i play back movie on another screen or have some game open in window

yshui commented 1 year ago

@Monsterovich nvidia 525.53 fixed a "stutter while moving windows" problem for GNOME, maybe that fixes our problem as well?

Monsterovich commented 1 year ago

@Monsterovich nvidia 525.53 fixed a "stutter while moving windows" problem for GNOME, maybe that fixes our problem as well?

I can't check, this driver is not in the repositories.

Utagai commented 1 year ago

@yshui A tremendously late response to your question here, I haven't been on my picom system to check in a while. I just ran nvidia-smi after a huge upgrade of the system: my driver version is 520.56.06.

It seems however, with the upgrade (and that of Thunderbird) the lagging has gone away and I can no longer reproduce it... :thinking:

Monsterovich commented 1 year ago

@yshui I'm working on a new project, my system monitor - conqie. Here I encountered the same problem when moving windows, and in xfwm4 compositor there is no problem.

This is a demo: https://youtu.be/hdZPe3mzTv8

Update: Windows start to lag if you move the transparent terminal window over the widget or move the widget itself. It also affects all windows.

Monsterovich commented 1 year ago

It seems however, with the upgrade (and that of Thunderbird) the lagging has gone away and I can no longer reproduce it...

@Utagai I think the Mozilla Thunderbird update fixed the bug in this particular case, but the bug is still there.

yshui commented 1 year ago

@Monsterovich did you manage to update your nvidia driver?

Monsterovich commented 1 year ago

did you manage to update your nvidia driver?

My current driver is 520.56.06.

Monsterovich commented 1 year ago

Disabling vsync in my application fixed the problem. But I don't understand why this problem is not present in xfwm4 compositor.

Utagai commented 1 year ago

@Monsterovich Yes, that's my theory too, since Thunderbird (for me at least) recently got a fairly big update, it likely changed something that no longer triggers this issue.

Monsterovich commented 1 year ago

@yshui Even if I move the window over the regular conky widget, I notice a slight lag on the 144hz screen when the conky widget updates. There is no such thing on the Intel GPU.

Monsterovich commented 1 year ago

Even if I move the window over the regular conky widget, I notice a slight lag on the 144hz screen when the conky widget updates. There is no such thing on the Intel GPU.

And when the widget updates, x_fence_sync takes a lot to complete which lags the terminal window.

изображение

Monsterovich commented 1 year ago

@yshui I updated the NVidia driver to 525.60.11. Picom still causes lags when moving windows when the conky widget is updated.

Monsterovich commented 1 year ago

After updating to Linux Mint 21, the bug fixed itself. I will close this ticket for now.