Comments (33)
@yshui Thanks for your input. I'll go with the patch to revert the commit for now as it's the less impacting solution for users in my opinion.
If we get a bug report on Arch side for that issue despite that, I'll redirect people to this thread so they have other potential solutions/workarounds to try on their side.
from picom.
@seiuneko, the glx case of this issue is tracked in #1145. however, we're not sure that this is the same issue. can you do what's described in #1145 (comment)? preferably with and without the #1181 applied with a minimal configuration where you're able to reproduce freezing.
from picom.
@Antiz96, i've tested it both on an nvidia gpu and on an intel igpu. given that it seems to fix the issue for me and knowing details about it i consider it a proper fix but i still would like it to be tested by someone else before merging.
from picom.
try --no-frame-pacing
.
from picom.
try
--no-frame-pacing
.
Hi,
That didn't help unfortunately... Launching picom with --no-frame-pacing
(while having vsync = true;
in the config file) is still impacted by the freezes.
from picom.
how long the freezes are typically?
from picom.
For video playback (youtube videos) they last for a few seconds (approximately 2 to 5).
For video games however, it gets frozen indefinitely until I click anywhere in the game window or unfocusing the game window (by moving my mouse outside of the window or on my secondary monitor). Weirdly enough, the mouse pointer itself isn't impacted by freezes, it's only the video/game window itself.
from picom.
The frequency of freezes is quite fast but a bit random. Sometimes I'll have a freeze only 3 seconds after the last one, sometimes it's only after 20/25 seconds since the last one.
But they are always frequent enough to have at least 2 to 3 freezes by minute on my side.
from picom.
may or may not be related to #1145. although that's been happening since v10.
don't know if you are familiar with git, you can use git bisect
to find out exactly when this started happening.
from picom.
yeah, i think that it could be the same issue as #1145. could you catch a more or less long freeze with trace logging (--log-level=TRACE --log-file=trace.log
) and upload the log? just run picom and try to stop it asap after a noticeable freeze.
from picom.
may or may not be related to #1145. although that's been happening since v10.
Well, could be but I confirm going back to v10.2 with vsync enabled does not produces such freezes on my side.
don't know if you are familiar with git, you can use
git bisect
to find out exactly when this started happening.
Sure, I'll do a bisecting as soon as I can.
In the mean time, I allowed myself to push a patch to the picom Arch Linux package to disable vsync by default in the config file as a temporary workaround.
from picom.
I had the exact same issue when updating today. Switching the backend from xrender
to glx
fixed it for me.
Also: Arch Linux, latest packages, i3wm, amdgpu.
from picom.
I had the exact same issue when updating today. Switching the backend from
xrender
toglx
fixed it for me.Also: Arch Linux, latest packages, i3wm, amdgpu.
I confirm switching to the glx
backend while keeping vsync enabled solves the issue as well.
So it seems like it's the combination of the xrender
backend and the vsync option being enabled that causes those freezes.
from picom.
yeah, i think that it could be the same issue as #1145. could you catch a more or less long freeze with trace logging (--log-level=TRACE --log-file=trace.log) and upload the log? just run picom and try to stop it asap after a noticeable freeze.
Here it is. There's 2 freezes in that trace. I tried to stop picom asap after the second freeze but there's a few seconds delay.
trace.log
from picom.
From the logs it looks like we didn't receive any damage events for a couple of seconds:
[ 01/24/2024 14:08:17.060 ev_handle TRACE ] event Damage serial 0x000070c4 window 0x00400429 "Baldur's Gate 3 (1920x1080) - (DX11) - (3 + 3 WT)"
[ 01/24/2024 14:08:17.060 queue_redraw VERBOSE ] Queue redraw, render_queued: 0, backend_busy: 0
[ 01/24/2024 14:08:17.060 repair_win TRACE ] Mark window 0x00400429 (Baldur's Gate 3 (1920x1080) - (DX11) - (3 + 3 WT)) as having received damage
[ 01/24/2024 14:08:17.060 add_damage TRACE ] Adding damage:
[ 01/24/2024 14:08:17.060 dump_region TRACE ] nrects: 1
[ 01/24/2024 14:08:17.060 dump_region TRACE ] (1920, 0) - (3840, 1080)
[ 01/24/2024 14:08:17.060 draw_callback_impl TRACE ] Schedule delay: 49 us
[ 01/24/2024 14:08:17.060 draw_callback_impl TRACE ] handle_pending_updates took: 2 us
[ 01/24/2024 14:08:17.060 paint_preprocess TRACE ] Window 0x0520005e ((null)) will not be painted because it is positioned outside of the screen
[ 01/24/2024 14:08:17.060 paint_preprocess TRACE ] Window 0x00400429 (Baldur's Gate 3 (1920x1080) - (DX11) - (3 + 3 WT)) will be painted
[ 01/24/2024 14:08:17.060 draw_callback_impl TRACE ] paint_preprocess took: 18 us
[ 01/24/2024 14:08:17.060 draw_callback_impl VERBOSE ] Render start, frame 846
[ 01/24/2024 14:08:17.061 paint_all_new TRACE ] Time spent on sync fence: 796 us
[ 01/24/2024 14:08:17.061 get_damage TRACE ] damage index: 0, damage ring offset: 1
[ 01/24/2024 14:08:17.061 dump_region TRACE ] nrects: 1
[ 01/24/2024 14:08:17.061 dump_region TRACE ] (1920, 0) - (3840, 1080)
[ 01/24/2024 14:08:17.061 paint_all_new TRACE ] Getting damage took 15 us
[ 01/24/2024 14:08:17.061 paint_all_new VERBOSE ] Render schedule deviation: 884 us (late) 8594539666 8594538782
[ 01/24/2024 14:08:17.077 draw_callback_impl VERBOSE ] Render end
[ 01/24/2024 14:08:26.675 ev_handle TRACE ] event Damage serial 0x000070e5 window 0x00400429 "Baldur's Gate 3 (1920x1080) - (DX11) - (3 + 3 WT)"
Does look very similar to #1145. If this only happens with NVIDIA, I wonder if we can chalk it up to poor support of XRender from NVIDIA...
In the mean time, I allowed myself to push a patch to the picom Arch Linux package to disable vsync by default
Since glx seems to work fine, can you instead make backend = "glx"
the default? thanks
from picom.
[...]
Does look very similar to #1145. If this only happens with NVIDIA, I wonder if we can chalk it up to poor support of XRender from NVIDIA...
Seems like it also happens with AMD actually.
In the mean time, I allowed myself to push a patch to the picom Arch Linux package to disable vsync by default
Since glx seems to work fine, can you instead make
backend = "glx"
the default? thanks
Done.
from picom.
[...]
don't know if you are familiar with git, you can usegit bisect
to find out exactly when this started happening.
Bisecting done, it revealed this commit as the "offending" one:
$ git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [b700a37d56ab5debdbb78be7a6b905e72f69ff2d] win: consider border when creating the mask image
git bisect good b700a37d56ab5debdbb78be7a6b905e72f69ff2d
# status: waiting for bad commit, 1 good commit known
# bad: [197b4bd396590cb5df61eb54ec6a1dadf1115a5d] Update CHANGELOG.md for v11 release
git bisect bad 197b4bd396590cb5df61eb54ec6a1dadf1115a5d
# good: [6bcda50170031ef95fa02bc1bf94f87947c66e44] Merge pull request #930 from omar-polo/openbsd/mesa-p
git bisect good 6bcda50170031ef95fa02bc1bf94f87947c66e44
# bad: [fea1dc794c19131f7f4eae2f4a0345516c615781] atom: add atoms associated with the background pixmap
git bisect bad fea1dc794c19131f7f4eae2f4a0345516c615781
# bad: [766f9f996f5a02d97d85e3c4cee34513501c758a] Merge pull request #986 from absolutelynothelix/fix-creating-eglpixmap
git bisect bad 766f9f996f5a02d97d85e3c4cee34513501c758a
# bad: [5a5ea76006125711061a72f4f972c58b48c2ab1d] event: restore event sequence number after passing it to Xlib handlers
git bisect bad 5a5ea76006125711061a72f4f972c58b48c2ab1d
# good: [8143c07de62371e3e1580addf8214b7d8cf61972] Update README.md
git bisect good 8143c07de62371e3e1580addf8214b7d8cf61972
# good: [882025092f52585fa5c88fef297a12472ec73314] Merge pull request #952 from yshui/dither
git bisect good 882025092f52585fa5c88fef297a12472ec73314
# good: [88608027b82d3777a6eed111018013640e1f3636] backend: add a comment
git bisect good 88608027b82d3777a6eed111018013640e1f3636
# bad: [23a29470e50ef1d68b9c99186b069659a793184c] backend: xrender: set update region for PresentPixmap request
git bisect bad 23a29470e50ef1d68b9c99186b069659a793184c
# good: [e407c5c7652da7e340e7c7797723b78be7ab1ab7] x: add x_{create,destroy}_region
git bisect good e407c5c7652da7e340e7c7797723b78be7ab1ab7
# first bad commit: [23a29470e50ef1d68b9c99186b069659a793184c] backend: xrender: set update region for PresentPixmap request
Just in case, note that not every "bad" commits gave me freezes as bad as the ones I'm describing in the initial issue (meaning either not as frequent or not as long) but, as playing the game with picom v10.2 or without picom running is a completely fluid and "freeze-free" experience, I still declared them as "bad" (bisecting wise).
I rebuilt a package for picom v11 locally, including this patch to revert the above "offending" commit and I confirm having no freezes with it.
from picom.
can't reproduce on an intel igpu. i ran picom with --config=/dev/null --backend=xrender --vsync
and had firefox playing a 4k 60fps video with few instances of glxgears spinning around with no freezes. i'll try to reproduce on an nvidia gpu later.
from picom.
@Antiz96 thanks!
from picom.
can reproduce on an nvidia gpu. we suspect that it caused by a race condition somewhere outside of picom, e.g. in libxcb as when a freeze happens there is a damage event before the destroy region request (the last added line in the offending commit bisected above) that we didn't receive and since we didn't receive and handle it we won't get any new damage events as they're incremental.
yshui can't reproduce this and said that i'm the only one who can fix this but i don't have a single idea what to do 😭
from picom.
huh, actually, i can reproduce it on an intel gpu and it looks the same.
from picom.
@absolutelynothelix Good to know you were able to reproduce the issue!
I remain available if you need more information/tests or anything that could help in its resolution :)
@yshui What do you recommended for the Arch package in the mean time?
Should I let the glx
backend the default in the config file for the moment (like it's currently the case) or should I leave the default configuration as it is and include the patch to revert the "offending" commit instead (while waiting for a fix)?
Unless you recommend otherwise, I would personally prefer the patch solution as it is totally transparent for users (whereas modifying the default config implies a manual change for people that have picom installed already).
But once again, if you think making the glx
backend the default is proper than the "reverting commit" patch, I'll just keep it that way for now ;)
from picom.
@Antiz96 from what we know so far, it looks like the same problem is happening with glx, and with v10 as well (#1145). that commit probably made this problem easier to hit for more people. I think having the patch to revert the commit is reasonable.
There is no "proper" solution at the moment, changing to glx
would also merely reduce the chance of this happening. I'll leave the decision making to you.
from picom.
@Antiz96 from what we know so far, it looks like the same problem is happening with glx, and with v10 as well (#1145). that commit probably made this problem easier to hit for more people. [...]
I confirm I still had similar but really rare freezes with the commit reverted. But I'm having like 1 per hour or so compared to 1 or 2 each 30 seconds before reverting the commit.
This is to say that the above quote may indeed probably be true. This commit may not be the one that introduced the freezes but it made them way more frequent. So there's a chance that those freezes were indeed already present with v10 but they were rare enough to not suspect/consider them being an actual issue (I probably thought they were "classic" time to time game lags) 😄
The current state with the reverted commit is totally acceptable though, it was just to go along with the above quote.
I hope this helps :)
from picom.
@Antiz96, can you test this patch and tell how it reduces the amount of freezes compared to reverting the offending commit? https://gist.githubusercontent.com/absolutelynothelix/b2220bdfe88fbaf1330b19b8c263ccc8/raw/21c9f097f97379d568beeae88d4e97bddef37b3b/man-i-love-xorg.patch
from picom.
@absolutelynothelix Sure, but I'm not home until Sunday so I won't be able to test it until then.
However, to add some precision to my previous message, the amount of freezes with the offending commit reverted is already pretty low. I said "1 per hour or so" but to be fair, I had like 2 or 3 during the entire day (at least that I could noticed).
It was mostly to "confirm" the theory that those freezes were eventually already there in v10.
Anyway, I'll go for a few hours long gaming session on Sunday with the above patch and I'll let you know (I've seen worst ways to test patches 😝).
Love the patch name BTW 😉
from picom.
@absolutelynothelix I went for a several hours gaming session yesterday with this patch applied and only faced 2 freezes during the entire session.
So pretty much the same as with the "offending" commit reverted.
from picom.
Also, thanks for #1167!
I'm updating the Arch package to v11.1 and dropping the patch ;)
from picom.
i think that we've found the root cause of this issue and now we have to think of a proper fix/workaround for it.
could anyone affected by this issue try this patch and tell if it's better than the current workaround? this patch has to be applied without the current workaround. the current workaround isn't present in the next branch, so applying this patch on top of the latest commit in the next branch should be fine.
also, this patch may have unexpected side-effects, so report back if you encounter something unusual that doesn't happen without it applied.
from picom.
Hi, I pushed a branch defroster
(#1181) which is an updated version of the patch, can someone test it?
from picom.
I also have the same problem, the Firefox browser freezes randomly. It improved after applying #1181 on the latest commit 0d3d18c, with the recovery time significantly reduced to about 1-2 seconds, previously it was several seconds long.
Platform
Arch Linux
GPU, drivers, and screen setup
NVIDIA GeForce RTX 3060 Mobile, nvidia-drivers 545.29.06-3, 1:23.3.5-1, single monitor with glx
glxinfo -B
name of display: :0
display: :0 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: 2823 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 545.29.06
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 545.29.06
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 545.29.06
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
Environment
awesome 4.3-3
picom version
vgit-0d3d1 with #1181
Diagnostics
Version: vgit-0d3d1
Extensions:
- Shape: Yes
- RandR: Yes
- Present: Present
Misc:
- Use Overlay: No
(Another compositor is already running) - Config file used: /home/seiuneko/.config/picom/picom.conf
Drivers (inaccurate):
NVIDIA
Backend: glx
- Driver vendors:
- GLX: NVIDIA Corporation
- GL: NVIDIA Corporation
- GL renderer: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2
Backend: egl
- Driver vendors:
- EGL: NVIDIA
- GL: NVIDIA Corporation
- GL renderer: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2
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;
# 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 = 'Notification'",
"class_g = 'Conky'",
"class_g ?= 'Notify-osd'",
"class_g = 'Cairo-clock'",
"_GTK_FRAME_EXTENTS@:c"
];
# Specify a list of conditions of windows that should have no shadow painted over, such as a dock window.
# clip-shadow-above = []
# 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.1
# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
fade-out-step = 0.1;
# 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.95;
# Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default)
# frame-opacity = 1.0
frame-opacity = 0.9;
# Let inactive opacity set by -i override the '_NET_WM_WINDOW_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 never 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 = gaussian
# blur-method = dual_kawase
# blur-size = 12
#
# blur-deviation = false
#
# blur-strength = 5
blur:
{
method = "dual_kawase";
size = 8;
deviation = 4.0;
strength = 3;
};
# 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 = 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'",
"window_type = 'tooltip'",
"window_type = 'popup_menu'",
"window_type = 'utility'",
"_GTK_FRAME_EXTENTS@:c"
];
#################################
# General Settings #
#################################
# Enable remote control via D-Bus. See the man page for more details.
# dbus = true
# 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_WINDOW_OPACITY' on client windows, useful for window managers
# not passing '_NET_WM_WINDOW_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 = 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. This usually means windows from the same application
# will be considered focused or unfocused at the same time.
# 'WM_TRANSIENT_FOR' has higher priority if detect-transient is enabled, too.
#
# detect-client-leader = false
# 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 = true;
# 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 = true
# Disable the use of damage information.
# This cause the whole screen to be redrawn every time, 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 = true
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 = true
# GLX backend: Use specified GLSL fragment shader for rendering window
# contents. Read the man page for a detailed explanation of the interface.
#
# window-shader-fg = "default"
# Use rules to set per-window shaders. Syntax is SHADER_PATH:PATTERN, similar
# to opacity-rule. SHADER_PATH can be "default". This overrides window-shader-fg.
#
# window-shader-fg-rule = [
# "my_shader.frag:window_type != 'dock'"
# ]
# 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
# Specify a list of conditions of windows that should never have transparent
# clipping applied. Useful for screenshot tools, where you need to be able to
# see through transparent parts of the window.
#
# transparent-clipping-exclude = []
# 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 = "error";
# 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.
#
# clip-shadow-above:::
# Controls whether shadows that would have been drawn above the window should
# be clipped. Useful for dock windows that should have no shadow painted on top.
#
# 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 = false; opacity = 0.75; focus = true; full-shadow = false; };
dock = { shadow = false; clip-shadow-above = true; }
dnd = { shadow = false; }
};
from picom.
Hi, I pushed a branch
defroster
(#1181) which is an updated version of the patch, can someone test it?
@yshui I've been very busy lately but if no one have tested it until then, I'll test it this week-end.
from picom.
@absolutelynothelix @yshui I installed a picom package built against the latest commit of the defroster
branch locally, went for a quick gaming session with it and didn't get any freezes, so it seems the new patch indeed fixes the issue :)
from picom.
Related Issues (20)
- High GPU usage with glx backend and frame-opacity <1 HOT 1
- shadow-r/g/b doesn't variate after the recent versions HOT 1
- Picom gets stuck (infinite loop?) with monitors in sleep and gets killed on wakeup HOT 4
- vsync stuttering with egl backend
- Exiting fullscreen mode with bspwm removes rounded corners HOT 13
- Windows redrawing problems with glx and software rendering (llvmpipe) HOT 2
- Replace libev with libuv HOT 2
- Border around GTK-dialogs HOT 22
- The screen displayed is abnormal HOT 3
- On KDE6 spectacle no longer becomes invisible while making rectangular selection HOT 6
- Lag when pressing keys in Vulkan application. HOT 8
- How to make picom clip all windows but "background" windows HOT 2
- `typedef`s in picom use suffix `_t` which is reserved by POSIX
- How can I achieve optimal performance without using optimus-manager? HOT 1
- RealTime option astounding HOT 1
- Improve error message if starting picom with a backend missing compile support
- The root window is not redrawn when changing the background HOT 3
- High CPU usage if vsync is disabled HOT 2
- Invalid extension event 161 & 146 HOT 1
- bug report HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from picom.