yshui / picom

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

shadow = true causes performance issues when dragging Chromium windows #151

Closed winteriscariot closed 9 months ago

winteriscariot commented 5 years ago

Platform

Arch Linux

GPU, drivers, and screen setup

Nvidia RTX 2060 with 144hz monitor

$ pacman -Q | grep nvidia lib32-nvidia-utils 418.56-1 nvidia 418.56-2 nvidia-settings 418.56-1 nvidia-utils 418.56-1

$ glxinfo -B name of display: :1 display: :1 screen: 0 direct rendering: Yes Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 6144 MB Total available memory: 6144 MB Currently available dedicated video memory: 5241 MB OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce RTX 2060/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 418.56 OpenGL core profile shading language version string: 4.60 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile

OpenGL version string: 4.6.0 NVIDIA 418.56 OpenGL shading language version string: 4.60 NVIDIA OpenGL context flags: (none) OpenGL profile mask: (none)

OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 418.56 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Environment

MATE

Compton version

$ compton --version v6-rc1-72-g9adba98

Compton configuration:

$ cat .config/compton.conf

#█▓▒░ shadows
shadow = true;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true;
shadow-radius = 5;
shadow-offset-x = -1;
shadow-offset-y = -1;
shadow-opacity = 0.25;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [
    "! name~=''",
    "n:e:Menu",
    "_GTK_FRAME_EXTENTS@:c",
    "name = 'Notification'",
    "name = 'Plank'",
    "name = 'Docky'",
    "name = 'Kupfer'",
    "name = 'xfce4-notifyd'",
    "name *= 'VLC'",
    "name *= 'compton'",
    "name *= 'Chromium'",
    "name *= 'Chrome'",
    "name *= 'Firefox'",
    "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'"
];
shadow-ignore-shaped = true;

#█▓▒░ opacity
#opacity-rule = [
# "50:class_g = 'PabloDraw'",
# "99:class_g = 'viewnoir'"
#];
menu-opacity = 1;
#inactive-opacity = 0.2;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;
alpha-step = 0.6;

#█▓▒░ fading
fading = true;
fade-delta = 5;
fade-in-step = 0.06;
fade-out-step = 0.06;
no-fading-openclose = true;

#█▓▒░ other
mark-wmwin-focused = true;
mark-ovredir-focused = true;
detect-rounded-corners = true;
detect-client-opacity = true;
backend = "glx";
vsync = true;
glx-no-stencil = true;
unredir-if-possible = true;
dbe = false;

Steps of reproduction

With the configuration pasted above, I get smooth dragging on normal environment windows (such as MATE Control Center, terminal, and others), however dragging a Chromium window around the desktop results in very bad, serious stuttering.

If I turn off compton then Chromium is smooth.

If I comment out shadow = true; from the config -- with no other changes -- Chromium is smooth

If I start compton from the command line using compton --config /dev/null --backend glx then Chromium is smooth (this is what first lead me to believe it was an issue with shadows)

If I have shadow = true set in the config then I get terrible stuttering.

One thing to note is that when I have shadow turned on, and I open a Chromium window, it causes all other windows to become laggy as well. When Chromium is either closed or minimized all other windows drag smoothly.

Expected behavior

Turning on shadows shouldn't cause such stuttering in Chromium

yshui commented 5 years ago

When did this start happening?

And it is kind of weird since you have Chromium in your shadow-exclude

winteriscariot commented 5 years ago

I only recently started using compton again (after switching to MATE from GNOME, tho that's a whole other story) and so I hadn't regularly used it in a number of years, so I can't say when this started, but it's been there since I started using Compton again.

What I can say, however, is that this problem seems to effect applications that use the Electron framework as well, which would make some sense since Electron is based on Chromium.

Signal Desktop, Discord, Slack, and Spotify (all Electron apps) seem to exhibit the same issues: whenever any of those windows are visible on screen, performance on moving windows around the screen takes a dive. As soon as I close or minimize those windows performance is great again. (For instance Firefox, GNOME Terminal, Steam, and a few others.)

Based on all this, I'm wondering if maybe the built-in compositor in Chromium (Aura) may be interacting negatively with shadows, for some reason? I feel like it's not about drawing shadows on the Chromium/Electron windows, but instead how they interact with the shadows on other windows

winteriscariot commented 5 years ago

EDIT: re: Electron apps, it seems that the Rocket.Chat desktop client (which is an Electron app) is not effected by this, so I'm going to poke a bit and see if I can find if there's anything in particular with that application that the others do not have set

winteriscariot commented 5 years ago

Interesting, when I pass the --use-gl=swiftshader-webgl switch to a chromium/electron based app (tested on chromium and spotify) i do not get the lag. however, I do get some errors in the console. From spotify:

[0330/150324.316670:ERROR:gpu_process_transport_factory.cc(990)] Lost UI shared context. [0330/150324.320529:ERROR:command_buffer_proxy_impl.cc(119)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer. [0330/150329.735111:ERROR:web_plugin_impl.cc(38)] Widevine registration is not supported after context initialization

yshui commented 5 years ago

Hmmm. This may not help, but can you use apitrace to capture a trace of compton, while you demostrate this problem?

Remember to pass --log-level=trace --log-file=/dev/null to compton.

yshui commented 5 years ago

Interesting, when I pass the --use-gl=swiftshader-webgl switch to a chromium

Maybe that flag broke hardware acceleration? You can tell if you are using hardware acceleration by looking at chrome://gpu

Ropid commented 5 years ago

I'm guessing you are seeing the same issue I had for years while using different NVIDIA cards.

I had the stutter problem also show up without Compton running, while using just a plain window manager with no compositor. I'm thinking Compton is probably innocent.

The problem is the CPU usage of the Xorg process going through the roof while moving windows around if certain programs are running. When the CPU usage of Xorg is hitting 100%, the terrible stutter shows up.

I can remember video players and Chromium increasing the chance for stutter with their hardware acceleration features enabled. Watching a 60fps stream on twitch.tv was always making the issue show up.

Gnome's "mutter" window manager seemed to behave better than other window managers. I heard somewhere that it tries to not update the Xorg server as much about changes while you move a window around.

I had the impression that setting my mouse to 500Hz instead of 1000Hz was helping a tiny bit.

Using compton's "xrender" backend plus the NVIDIA driver's "force full composition pipeline" setting seemed to behave better than using compton's "glx" backend plus compton's vsync.

Over the years, occasionally I went on a long search for anything new about the issue but never found something that fixed it. What was strange is that there was barely any discussion about this online. Maybe not all people have this issue with Xorg CPU usage going crazy on NVIDIA drivers? The last time I used NVIDIA was perhaps nine months ago. I don't know if something changed since then.

The "solution" I settled on was switching to a tiling window manager and simply not moving windows around.

winteriscariot commented 5 years ago

Interesting, when I pass the --use-gl=swiftshader-webgl switch to a chromium

Maybe that flag broke hardware acceleration? You can tell if you are using hardware acceleration by looking at chrome://gpu

You are 100% correct, it was all software rendering. Correspondingly, when I turn off hardware acceleration by turning it off in chrome://settings the lag disappears as well.

I'm going to continue to see if there are any combination of settings between chrome and compton that might make everything work together nicely.

yshui commented 9 months ago

most likely a driver problem. also old.