artifacts and poor performance of shadows in the xrender backend #1349
Comments
|
For my system with 4500U xrender outright freezes the screen on start and then it starts lagging and glitching |
|
Yes it freezes for like 1 or 2 seconds. but then every interaction also causes it. so running glxgears and then simply changing focus will cause it to not even render. Glxgears with go form 5000 fps to 50. but it doesn't actually show anything. And Firefox is unusable because each interaction takes a second or more. I thought my SSD was dieing. |
|
Seeing this on NixOS as well. Versions: Switching backend to glx seems to fix things. Probably also worth noting that the freezing seems to be CPU-bound - I see the X process' CPU spiking in the time between trying to open a new terminal and seeing it actually render. |
|
I can confirm this on both Artix Linux and FreeBSD running on Intel (using the GPU of the processor). A lot of lagging, especially running stuff in xterm, like looking through directories with Midnight Commander. Also using Vim/Neovim causes lagging, opening a file, nothing happens until after a lag. This is using Picom 12.1 on i3. |
|
Oh, this problem is on glx as well on my systems. |
do you happen to use wezterm? |
|
Yeah my CPU hits 100% when interacting with a window or switching. It's not terminal specific. My firefox did it with each interaction. I thought my computer was broken. Also glx doesn't seem to be as good. There is some stuttering too. But no where near the issues with xrender. |
|
the xrender backend is slow by itself. it should be gpu-accelerated but it's still quite heavy on the cpu. there are optimization possibilities but this is not in the priority. officially it's set as the default backend in the example configuration file because it was considered to be a safe fallback a long time ago. we were discussing making the glx backend the new default a while ago so maybe it's time to finally do this. i don't see issues with the xrender backend other than this from my short test run. |
|
Prior to picom 12, I used xrender for years without issue. It was as slow
as grease lightning. Its only an issue in picom 12. Its not slow it hangs
the sysyem. That's what we mean by slow. It freezes and unfreezes the
sysyem over and over making it unusable. Glx almost works as fast but it
is slower and also seems to stutter the system.
…On Tue, 8 Oct 2024, 14:52 Maxim Solovyov, ***@***.***> wrote:
the xrender backend is slow by itself. it should be gpu-accelerated but
it's still quite heavy on the cpu. there are optimization possibilities but
this is not in the priority. officially it's set as the default backend in
the example configuration file because it was considered to be a safe
fallback a long time ago. we were discussing making the glx backend the new
default a while ago so maybe it's time to finally do this. i don't see
issues with the xrender backend other than this from my short test run.
—
Reply to this email directly, view it on GitHub
<#1349 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/BGC7QTOYMO6KVBBCWE4MM5LZ2PPQPAVCNFSM6AAAAABPOWDGVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZHEYTCMBYHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
@ProgrammingRainbow i feel you didn't answer my question? |
|
I am experiencing this exact same problem with Setting the backend to |
|
@Cyan903 thanks for the info. do you use blur with xrender? and the CPU spike is from Xorg, right? |
I don't use blur with 2024-10-09.11-26-04.mp4 |
|
Seeing the same issue here (with Openbox and a Radeon RX Vega 56 GPU). Here my picom configuration, if it can help answer whether blur is used. ~/.config/picom.conf#################################
# 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;
# 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;
# Avoid drawing shadows on dock/panel windows. This option is deprecated,
# you should use the *wintypes* option in your config file instead.
#
# no-dock-shadow = false
# Don't draw shadows on drag-and-drop windows. This option is deprecated,
# you should use the *wintypes* option in your config file instead.
#
# no-dnd-shadow = false
# 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
# Do not paint shadows on shaped windows. Note shaped windows
# here means windows setting its shape through X Shape extension.
# Those using ARGB background is beyond our control.
# Deprecated, use
# shadow-exclude = 'bounding_shaped'
# or
# shadow-exclude = 'bounding_shaped && !rounded_corners'
# instead.
#
# shadow-ignore-shaped = ''
# Specify a list of conditions of windows that should have no shadow.
#
# examples:
# shadow-exclude = "n:e:Notification";
#
# shadow-exclude = []
shadow-exclude = [
"name = 'Notification'",
"class_g = 'Conky'",
"class_g ?= 'Notify-osd'",
"class_g = 'Cairo-clock'",
"_GTK_FRAME_EXTENTS@:c"
];
# 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 = true
# Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028)
# fade-in-step = 0.028
fade-in-step = 0.03;
# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
# fade-out-step = 0.03
fade-out-step = 0.03;
# 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.9;
# Default opacity for dropdown menus and popup menus. (0.0 - 1.0, defaults to 1.0)
# menu-opacity = 1.0
# 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 = []
#################################
# Background-Blurring #
#################################
# Parameters for background blurring, see the *BLUR* section for more information.
# blur-method =
# blur-size = 12
#
# blur-deviation = false
# 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 = false
# 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 = false
# Use fixed blur strength rather than adjusting according to window opacity.
# blur-background-fixed = false
# 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 = [
"window_type = 'dock'",
"window_type = 'desktop'",
"_GTK_FRAME_EXTENTS@:c"
];
#################################
# 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 = "xrender";
# 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;
# Specify refresh rate of the screen. If not specified or 0, picom will
# try detecting this with X RandR extension.
#
# refresh-rate = 60
refresh-rate = 0
# Limit picom to repaint at most once every 1 / 'refresh_rate' second to
# boost performance. This should not be used with
# vsync drm/opengl/opengl-oml
# as they essentially does sw-opti's job already,
# unless you wish to specify a lower refresh rate than the actual value.
#
# sw-opti =
# 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 = false
# 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 = []
# 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 = true; shadow = true; opacity = 0.9; focus = true; full-shadow = false; };
dock = { shadow = false; }
dnd = { shadow = false; }
popup_menu = { opacity = 0.9; }
dropdown_menu = { opacity = 0.9; }
};Switching to the glx backend seems like a good solution. |
|
Having this problem too, switching backend to glx fixed it for me. Picom: v12.1 (/startdir/picom revision c321da4) OS: Arch Linux Config: |
|
can you try disabling shadow as well? |
|
I'm not using shadows.
…On Thu, 10 Oct 2024, 08:50 Yuxuan Shui, ***@***.***> wrote:
can you try disabling shadow as well?
—
Reply to this email directly, view it on GitHub
<#1349 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/BGC7QTMSUXLQU5Q7ECNZWJTZ2YWWFAVCNFSM6AAAAABPOWDGVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBUGMZTQMJYGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
hmm, which xf86-video driver do you use? is it modesetting or amdgpu? there really isn't enough info to work off of. if you can, try profiling the X server and see what's using so much CPU in there. |
|
For my part I'm using xf86-video-amdgpu as the driver. Deactivating shadows makes the lag disappear. Attempting to profile CPU usage with Sysprof indicates that most time is spent by Xorg in
|
|
hmm, conflicting information here. is this actually related to shadows or not? 🤔 |
|
I'm sorry i did not understand before about the shadowing. I'm not using any thing that looks like shadows but yes it is enabled in the config. I went back to picom 11 with shadow enabled and xrender is fine. in picom 12 all versions shadow is still on but xrender causes the issue. With shadow off and xrender it is fast again yes. I am using amdgpu no special settings just default out of the box archlinux. try profiling the X server and see what's using so much CPU in there. Certainly. Uh, but how? In htop it was xorg that was taking 100% cpu. There is actually14 xorg running but just 1 spikes to 100% and the whole system freezes. |
yshui
changed the title
you might need sudo. more resources on how to perf: https://www.brendangregg.com/perf.html, https://perf.wiki.kernel.org/index.php/Tutorial |
|
A whole lot of this. 14.57% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012328 ◆ |
|
so same story as #1349 (comment) but i do need to see the function names though... maybe you need to install debug symbols for pixman? |
|
i also wonder if the modesetting driver will help. if you can, try just remove |
|
Do i need to recompile pixman? I'm just using the arch package. is there an aur that debuging or a switch i can use? |
|
it's a bit complicated. you are using X & pixman from archlinux repo, right? in that case, upload your |
|
Does this help? 47.58% Xorg libpixman-1.so.0.43.4 [.] __bits_image_fetch_general |
|
ok, i think this is it. turns out i am both right and wrong. i was right that xf86-video-amdgpu does certain operations picom needs (specifically convolution filters) rather inefficiently. i was wrong in the sense that, modesetting isn't any better either. we just had a workaround for it in place: picom/src/backend/xrender/xrender.c Lines 959 to 962 in 8370ebf |
Well, except xf86-video-intel. Fixes #1349 Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This comment was marked as off-topic.
This comment was marked as off-topic.
absolutelynothelix
added
bug
backend: xrender
|
tl;dr use the modesetting ddx driver instead of the intel's one. we have two paths of generating and rendering shadows in the xrender backend:
we used to assume that all the vendors' ddx drivers have a proper accelerated convolution filter but this assumption turned to be wrong. we started to assume that the intel's ddx driver has it but this assumption turned to be wrong as well - it indeed has an accelerated convoltion filter but it's quite limited and isn't enough for picom's needs. in the end it turned that the "fast" path is actually slow and the "slow" path is actually fast. the "fast" path also has a rendering issue that may be a bug on our side. for now the issues mentioned above affect only the intel's ddx driver. it's advised to use the modesetting ddx driver instead of the intel's one simply because of the latter being abandoned and instead of all the vendors' ddx drivers in general because they're all cursed ahh. |
absolutelynothelix
changed the title
|
an update on artifacts: there are indeed artifacts but they're only present when the intel's ddx driver is used so the situation for it is:
so the only usable shadow radius for it is 1 😂 |
a (hopefully temporary) workaround for #1349.
absolutelynothelix
added
revisit
|
i pushed a (hopefully temporary) workaround for all the issues with shadows in the xrender backend to the leaving this open until we decide what to do with everything we learned about ddx drivers. |
I just test your last commit, yes artifacts and poor performance are gone (In my case). I tested with big shadow radius like 20 and with the default one.
Update: There is still a little bad performance with big shadow radius like 20 for example. The defaults works fine or at least is not notorious. |
a (hopefully temporary) workaround for #1349.
a (hopefully temporary) workaround for yshui#1349.
Running Archlinux and updated my system running Xmonad. The system because increasingly slow as in 1 to 2 second lag. I found the Xorg was running 100% just changing focus or transitioning. Even firefox wasn't resounding properly. Killing picom fixed it. So i started trying different backends and also different versions. It seems Picom-11 used xrender backend and that worked find. But Picom-12 it doesn't work with xrender. Some of the packages had it set to xrender in /etc/xdg/picom.conf and some had it set to glx. The latest is xrender which slowed me down. So for now switching to glx is working. but it seems xrender is bugged and set as the default in archlinux. I am using an AMD 5700u APU if that helps with the latest archlinux packages using the standard mesa open source drivers.
The text was updated successfully, but these errors were encountered: