Giter VIP home page Giter VIP logo

Comments (33)

Antiz96 avatar Antiz96 commented on August 28, 2024 1

@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.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024 1

@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.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024 1

@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.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024

try --no-frame-pacing.

from picom.

Antiz96 avatar Antiz96 commented on August 28, 2024

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.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024

how long the freezes are typically?

from picom.

Antiz96 avatar Antiz96 commented on August 28, 2024

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.

Antiz96 avatar Antiz96 commented on August 28, 2024

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.

yshui avatar yshui commented on August 28, 2024

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.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024

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.

Antiz96 avatar Antiz96 commented on August 28, 2024

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.

Leo1998 avatar Leo1998 commented on August 28, 2024

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.

Antiz96 avatar Antiz96 commented on August 28, 2024

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.

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.

Antiz96 avatar Antiz96 commented on August 28, 2024

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.

yshui avatar yshui commented on August 28, 2024

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.

Antiz96 avatar Antiz96 commented on August 28, 2024

[...]
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.

Antiz96 avatar Antiz96 commented on August 28, 2024

[...]
don't know if you are familiar with git, you can use git 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.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024

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.

yshui avatar yshui commented on August 28, 2024

@Antiz96 thanks!

from picom.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024

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.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024

huh, actually, i can reproduce it on an intel gpu and it looks the same.

from picom.

Antiz96 avatar Antiz96 commented on August 28, 2024

@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.

yshui avatar yshui commented on August 28, 2024

@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 avatar Antiz96 commented on August 28, 2024

@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.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024

@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.

Antiz96 avatar Antiz96 commented on August 28, 2024

@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.

Antiz96 avatar Antiz96 commented on August 28, 2024

@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.

Antiz96 avatar Antiz96 commented on August 28, 2024

Also, thanks for #1167!
I'm updating the Arch package to v11.1 and dropping the patch ;)

from picom.

absolutelynothelix avatar absolutelynothelix commented on August 28, 2024

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.

yshui avatar yshui commented on August 28, 2024

Hi, I pushed a branch defroster (#1181) which is an updated version of the patch, can someone test it?

from picom.

seiuneko avatar seiuneko commented on August 28, 2024

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.

Antiz96 avatar Antiz96 commented on August 28, 2024

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.

Antiz96 avatar Antiz96 commented on August 28, 2024

@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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.