Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

picom considerably slower than xcompmgr #344

Closed
Hippo0o opened this issue Mar 20, 2020 · 36 comments
Closed

picom considerably slower than xcompmgr #344

Hippo0o opened this issue Mar 20, 2020 · 36 comments
Labels

Comments

@Hippo0o
Copy link

Hippo0o commented Mar 20, 2020

Platform

Platform: Arch linux amd64 kernel 5.4

GPU, drivers, and screen setup

Radeon RX 580, amdgpu
xrandr --output DisplayPort-2 --primary --mode 5120x1440 --rate 120 --pos 0x0 --rotate normal --set TearFree on

$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: Radeon RX 580 Series (POLARIS10, DRM 3.35.0, 5.4.23-1-MANJARO, LLVM 9.0.1) (0x67df)
    Version: 19.3.4
    Accelerated: yes
    Video memory: 8192MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 4.5
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 7352 MB, largest block: 7352 MB
    VBO free aux. memory - total: 8131 MB, largest block: 8131 MB
    Texture free memory - total: 7352 MB, largest block: 7352 MB
    Texture free aux. memory - total: 8131 MB, largest block: 8131 MB
    Renderbuffer free memory - total: 7352 MB, largest block: 7352 MB
    Renderbuffer free aux. memory - total: 8131 MB, largest block: 8131 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 8192 MB
    Total available memory: 16384 MB
    Currently available dedicated video memory: 7352 MB
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.35.0, 5.4.23-1-MANJARO, LLVM 9.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.3.4
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Environment

i3-gaps 4.18

picom version

**Version:** v7.5

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes
* Config file used: ~/.config/compton.conf

### Drivers (inaccurate):

AMDGPU, Radeon 

Configuration:

# Shadow
shadow = true;			# Enabled client-side shadows on windows.
shadow-radius = 3;		# The blur radius for shadows. (default 12)
shadow-offset-x = -3;		# The left offset for shadows. (default -15)
shadow-offset-y = -3;		# The top offset for shadows. (default -15)
shadow-opacity = 0.75;		# The translucency for shadows. (default .75)
#shadow-red = 0.58;		# Red color value of shadow. (0.0 - 1.0, defaults to 0)
#shadow-green = 0.88;		# Green color value of shadow. (0.0 - 1.0, defaults to 0)
#shadow-blue = 0.89;		# Blue color value of shadow. (0.0 - 1.0, defaults to 0)
shadow-exclude = [ ];		# Exclude conditions for shadows.
shadow-ignore-shaped = true;	# Avoid drawing shadow on all shaped windows
				# (see also: --detect-rounded-corners)

# Fading
fading = false;			# Fade windows during opacity changes.
fade-delta = 10;		# The time between steps in a fade in milliseconds. (default 10).
fade-in-step = 0.05;		# Opacity change between steps while fading in. (default 0.028).
fade-out-step = 0.06;		# Opacity change between steps while fading out. (default 0.03).
# no-fading-openclose = true;	# Avoid fade windows in/out when opening/closing.
fade-exclude = [ ];		# Exclude conditions for fading.

# Other
backend = "glx"			
#refresh-rate = 0;		
vsync = false;
glx-no-rebind-pixmap = true
glx-no-stencil = true
xrender-sync-fence = true


# Window type settings
wintypes:
{
  tooltip = { fade = false; shadow = true; opacity = 0.99; focus = true; };
  #toolbar = { fade = false; shadow = true; opacity = 0.99; focus = true; };
  #normal = { fade = false; shadow = true; opacity = 0.99; focus = true; };
  menu = { fade = false; shadow = true; opacity = 0.99; focus = true; };
  #dialog = { fade = false; shadow = true; opacity = 0.99; focus = true; };
  popup_menu = { fade = false; shadow = true; opacity = 0.99; focus = true; };
};

Expected behavior

xcompmgr like performance

Current Behavior

slower & stuttering

Other details

I noticed a lot of slowdowns and stuttering while dragging floating windows and resizing them.
I tried glx and xrender backend with enabling and disabling some glx options.
It was worse with vsync enabled which i disabled because i can use the gpu drivers vsync.
I also got a similar setup with a nvidia gtx 970, nvidia-lts, ForceCompositionPipeline=On, 1080p 240hz using xrender backend which has the same problems (testing xcompmgr on it later).

I experience stuttering while watching twitch and dragging a transparent window over it.
When dragging a transparent terminal over another terminal it lags behind the curser. (glx only)
Resizing certain floating windows stutters a lot.
I also notice a little stutter while dragging in general (like 60hz window movement on 120hz monitor)
Only on nvidia: moving a chrome window with animations/videos in it is stuttering from time to time.

Today i tried xcompmgr and i got no stuttering at all. Overall im not noticing any slowdowns.
config used: xcompmgr -c -C -t-5 -l-5 -r3.3 -o.33

@Hippo0o
Copy link
Author

Hippo0o commented Mar 20, 2020

On nvidia i get similar results.
xcompmgr gives me shadows and transparency while it isn't slower than no compositor.
picom is noticebly slower in some cases compared to no compositor.

@absolutelynothelix
Copy link
Collaborator

absolutelynothelix commented Mar 20, 2020

so you basically have single rx580 handling two 2k 120hz monitors? i'm not sure about rx580 performance but that sounds like a problem. what's your overall performance? what if you leave only one monitor?

can you please compare performance between --experimental-backends --backend glx, --backend glx, --experimental-backends --backend xrender, --backend xrender with your config? which one gives you the best feeling?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

Its 1 ultrawide monitor. I can't test the rx580 setup for the next few days since its my pc at work.
But i can say that i testet all of those 4 options and got same results for my above mentioned problems. Especially the resizing lag/stuttering/freezing of said floating window didn't change.
While randomly testing --backend xrender --benchmark 1000 and --backend glx --benchmark 1000 the time difference was ~2sec vs ~1sec. idk if that helps.
I will upload a video of my 2x 1080p 240h,60hz monitor nvidia setup showing an example of what i mean.

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

Setup: nvidia gtx 970, nvidia-driver 440.64 (main problems equal to above mentioned setup)
Monitor settings

xrandr --output DVI-D-0 --mode 1920x1080 --pos 0x0 --rotate left --output DP-0 --primary --mode 1920x1080 --rate 240 --pos 1080x350 --rotate normal 
nvidia-settings --assign CurrentMetaMode="DP-0: 1920x1080_240 +1080+350 {ForceCompositionPipeline=On}, DVI-D-0: nvidia-auto-select +0+0 {rotation=left, ForceCompositionPipeline=On}"

https://www.youtube.com/watch?v=PYXiw7ivUa8 testing picom and xcompmgr.
Idk why obs stutters with xcompmgr tho.
https://www.youtube.com/watch?v=Z3Uh0wj8gtA i made a cheap phone recording to prove xcompmgr being smooth compared to picom.

@yshui yshui added the bug label Mar 21, 2020
@yshui
Copy link
Owner

yshui commented Mar 21, 2020

This could be a bug rather than a performance problem. Unfortunately I don't have a high refresh rate monitor to reproduce this problem.

Can you turn on trace logging and attach a log file? I will have a look, but don't hold your breath.

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

logs.tar.gz
i did:
strace picom &> picom.strace
apitrace trace picom
picom --log-level=debug &> picom.log
just dragging a floating glxgears

@yshui
Copy link
Owner

yshui commented Mar 21, 2020

Can you do --log-level=trace?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

i did try 1 monitor 60hz but results were the same.

@absolutelynothelix
Copy link
Collaborator

please, upload your log to pastebin/hastebin/whateverbin and edit your comment to include link to log instead the log itself.

@yshui
Copy link
Owner

yshui commented Mar 21, 2020

@Hippo0o I added some more logs, can you fetch the latest next branch, and attach the --log-level=trace log again?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

using picom-git aur:

$ picom --diagnostics                                                                     
**Version:** vgit-33a5c

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes* Config file used: None

### Drivers (inaccurate):

NVIDIA  

the lag is better but till there

@yshui
Copy link
Owner

yshui commented Mar 21, 2020

@Hippo0o you are 1 commit behind. can you rebuild and get the trace log again?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

picom.log
its performing a lot better

@yshui
Copy link
Owner

yshui commented Mar 21, 2020

@Hippo0o

its performing a lot better

How much better? Is this still a problem? If it's fine with you, can you upload a new video?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

@yshui idk why but its as worse as before again with newer version
https://www.youtube.com/watch?v=OfDWSq8d8qU
i will reboot and try again i guess.

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

@yshui i found out why
i have to install the picom-git package from aur to have better performance with newest build from git?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

when i remove /etc/xdg/picom.conf which isnt included in the picom-git package it works better

@yshui
Copy link
Owner

yshui commented Mar 21, 2020

Can you upload a video of the "good" version?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

removing

"_GTK_FRAME_EXTENTS@:c",
"_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"

from the shadow-exclude list makes the freezes go away but the window still lags behind the cursor.
Im sure tho that it is the performance increase i mentioned

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

@Hippo0o
Copy link
Author

Hippo0o commented Mar 21, 2020

i did another comparision to xcompmgr https://www.youtube.com/watch?v=3YxxiQUsHwU

@yshui
Copy link
Owner

yshui commented Mar 23, 2020

@Hippo0o is there any difference between the xrender and the glx backends? And does toggling --experimental-backends make any difference?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 23, 2020

@yshui for all the problems i described there is no difference between those options.
I also tested the same scenarios on my intel(modesetting) gpu laptop and there were no such problems at all. It runs really well.

@WillPower3309
Copy link

Could potentially be an ultra-wide issue, I have similar (albeit less) stuttering on my 2560 x 1080 60 hz panel.

@TheToto
Copy link

TheToto commented Apr 16, 2020

I have the same problem on a simple 1920*1080 screen, amd cpu/gpu
Dragging is OK but resizing is really slow.

@Elserjo
Copy link

Elserjo commented May 19, 2020

I also can confirm problem with laggy windows on 1920*1080 and nvidia 1070 on picom 8.1 (and it was on prev versions). It happens when i open some another window with OpenGL context, it could be mpv or Firefox (with toggled on open gl compositing)
options as xrender or experimental-backends doesn't give any effect.

#366

@66RING
Copy link

66RING commented May 27, 2020

I have the same problem on a simple 1920*1080 screen, amd cpu/gpu
Dragging is OK but resizing is really slow.

same

@billksun
Copy link

@Sushisource
Copy link

@billksun At least in my case, I have it properly blacklisted and still experiencing super slow resizing and slow dragging.

@TheToto
Copy link

TheToto commented Sep 10, 2020

Wow, I tested again picom today and it is as fast as xcompmgr now.

@Mange
Copy link

Mange commented Nov 20, 2020

I have 3 1440p screens, two at 75 Hz and one at 144 Hz, and when picom is running I can move around windows at around 20 fps. If I kill the process it will allow me to move around windows at the correct framerate.

I use Nvidia RTX2070 (with official drivers) + X11 + Awesome WM + picom fork with kawase blue and rounded corners.

Picom config
backend = "glx";
dbe = false;
detect-client-opacity = true;
detect-rounded-corners = true;
glx-no-stencil = true;
glx-swap-method = 2;
refresh-rate = 0;
vsync = true;

# Shadow
shadow = false; # Disabled for rounded corners for now
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
shadow-opacity = 0.8;
shadow-red = 0.0;
shadow-green = 0.0;
shadow-blue = 0.0;

shadow-exclude = [
  "name = 'Notification'",
  "class_g ?= 'Notify-osd'",
  "_GTK_FRAME_EXTENTS@:c",
  "class_g ?= 'i3-frame'",
  "class_i *= 'polybar'",
  "class_i *= 'tray'",
  "class_g *= 'screenshot'",
  "class_g = 'slop'",
  "class_g = 'Conky'",
  "class_g = 'GLava'",
  "class_g = 'Firefox' && argb",
  "class_g = 'Popup'",
  "n:a:Conky",
  "class_g ?= 'maim'",
  "fullscreen",
  "width >= 3440"
];

# For i3 tabs support for flashfocus
opacity-rule = [
  "0:_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"
];

# Blur background
blur-background = true; # Blur background of semi-transparent / ARGB windows.
blur-background-frame = true; # Blur background of windows when the window frame is not opaque. Implies --blur-background.
blur-background-fixed = true; # Use fixed blur strength instead of adjusting according to window opacity.
blur-method = "kawase"; # requires picom fork
blur-strength = 8; # requires picom fork

blur-background-exclude = [
    "class_i *= 'tray'",
    "class_g = 'Firefox' && argb",
    "class_g = 'conky'",
    "class_g = 'GLava'",
    "class_g ?= 'maim'",
    "class_g *= 'screenshot'",
    "class_g ?= 'slop'"
];

# Fading
# Fading just makes things feel slower IMO...
fading = false;
fade-exclude = [
    "width >= 3440",
    "class_g *= 'screenshot'",
    "class_g = 'slop'",
    "fullscreen"
];

# Rounded corners
corner-radius = 10.0;
round-borders = 1;

rounded-corners-exclude = [
  "class_g = 'awesome'",
  "class_g = 'Polybar'",
  "class_g = 'Firefox' && argb"
];

# Window type settings
wintypes:
{
  tooltip = { fade = true; shadow = true; opacity = 0.85; focus = true; };
  dock = { shadow = false; }
  dnd = { shadow = false; }
  popup_menu = { opacity = 0.9; }
  dropdown_menu = { opacity = 0.9; }
};

--experimental-backends does not do any difference here, although --experimental-backends fixes other display issues like flickering windows. Same config works well on my laptop with Intel / 1080p 60Hz.

If I disable blurred backgrounds AND rounded corners, then the problem is fixed. Just one of them does not, although blur and no rounded corners have a slightly better framerate than having both enabled. Could it be shader related? I've tried putting the card in "Maximum performance mode" in the Nvidia X Server Settings app.

Is there anything I should try to change in order to find a cause?

@Hippo0o
Copy link
Author

Hippo0o commented Mar 8, 2022

From my recent experience, picom got a lot faster and is mostly on top or on par with xcompmgr as far as i can observe.

Although i still have some issues, picom with --experimental-backends is really smooth for the most part and i recommend using it.

@Hippo0o Hippo0o closed this as completed Mar 8, 2022
@Hippo0o
Copy link
Author

Hippo0o commented Nov 23, 2022

@asklow I would suggest using the vsync setting from your graphics driver

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

11 participants