Picom stops drawing during games, until alt-tab

[gregflynn]

Platform

Arch Linux (updated)

GPU, drivers, and screen setup

Nvidia 2080, nvidia 545.29.02-2, mesa 1:23.2.1-2

Single monitor 3840x1600

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 8192 MB
    Total available memory: 8192 MB
    Currently available dedicated video memory: 7405 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 2080/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 545.29.02
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.02
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.02
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Environment

AwesomeWM + picom

picom version

picom 10.2-1

Diagnostics

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 = true;

# The blur radius for shadows, in pixels. (defaults to 12)
shadow-radius = 10;

# 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 = -10;

# The top offset for shadows, in pixels. (defaults to -15)
shadow-offset-y = -10;

# 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",

  "class_g ~= 'xdg-desktop-portal' && _NET_FRAME_EXTENTS@:c && window_type = 'dialog'",
  "class_g ~= 'xdg-desktop-portal' && window_type = 'menu'",
  "_NET_FRAME_EXTENTS@:c && WM_WINDOW_ROLE@:s = 'Popup'",
  "class_i = 'Firefox' && window_type = 'utility'",
  "class_i = 'Firefox' && window_type = 'popup_menu'",
  "class_g = 'xdg-desktop-portal-gnome' && window_type = 'menu'",
];

# 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 monitor to that monitor. This is
# currently implemented using the X RandR extension.
# crop-shadow-to-monitor = 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.05;

# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
# fade-out-step = 0.03
fade-out-step = 0.05;

# The time between steps in fade step, in milliseconds. (> 0, defaults to 10)
# fade-delta = 10
fade-delta = 5;

# 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

# Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default)
# frame-opacity = 1.0

# 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 =
# blur-size = 12
#
# blur-deviation = false
#
# blur-strength = 5

# 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 = ""


# Exclude conditions for background blur.
# blur-background-exclude = []
# blur-background-exclude = [
#   "window_type = 'dock'",
#   "window_type = 'desktop'",
#   "_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`, `egl` or `xr_glx_hybrid`.
# `xrender` is the default one.
#
# backend = "glx"
backend = "glx";

# Use higher precision during rendering, and apply dither when presenting the
# rendered screen. Reduces banding artifacts, but might cause performance
# degradation. Only works with OpenGL.
dithered-present = false;

# Enable/disable VSync.
# vsync = false
vsync = true;

# 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 = 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 '_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;

# 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 = 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 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
#
use-damage = false;

# 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"

# 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 = true; opacity = 1; focus = true; full-shadow = false; };
  dock = { shadow = false; clip-shadow-above = true; }
  dnd = { shadow = false; }
#   popup_menu = { opacity = 0.9; }
#   dropdown_menu = { opacity = 0.9; }
};

Steps of reproduction

1. Launch Civ 6
2. Get sucked into an international conflict
3. Screen will freeze periodically, either in windowed mode or fullscreen
4. Screen unfreezes if I alt tab or select another window on the keyboard

I have confirmed that killing picom prior to game will result in no freezing

Expected behavior

Continue to draw in games

Current Behavior

Seemingly random screen draw freezes during game play

Stack trace

OpenGL trace

Working on repro during trace now, will edit and post when i get it

Other details

[Helyos96]

I can confirm having the same issue, although I don't know for sure that picom is causing it (I'll have to play with picom disabled for a while and see if I get any random graphical freeze, like OP).

Fullscreen games, usually powered by wine/dxvk, will periodically stop rendering and freeze frame (although they keep "playing" just fine), and only a virtual desktop switch will let the frames render again.

Archlinux - next-git (a6b4e28) - Nvidia 545.29.02 - i3wm

[scfarley]

I only noticed this today after installing picom for the first time, so I suspect it is picom. When this happens, the game continues running since I hear all the sounds from it.

The games where I saw this:

• Rocket League
• SuperTuxKart

Environment:

• FreeBSD 13.2-STABLE
• Nvidia 525.147.05
• Fluxbox 1.3.7
• Wine 8.20
• DXVK 2.2
• Picom 10.2

[ssipos90]

yup, happens to me too in all games. I usually turn off picom when playing games and it doesn't happen anymore, but for some reason, Wine/Proton 8 doesn't work without a compositor and some games don't work on wine/proton 6 or 7.

freakin linux..

[Daniel-McLarty]

I have the same bug, but for me the mouse will still move and since I have 2 screens I can fix it by moving the mouse across screens.

[Daniel-McLarty]

@gregflynn By chance do you have any of the following that I also have?
Force Full Composition Pipeline enabled in NVIDIA settings, high refresh rate monitors, and or dual monitors of different refresh rates or sizes?
I am wondering if any "strange" configurations are tied to the freezes.

[gregflynn]

@gregflynn By chance do you have any of the following that I also have? Force Full Composition Pipeline enabled in NVIDIA settings, high refresh rate monitors, and or dual monitors of different refresh rates or sizes? I am wondering if any "strange" configurations are tied to the freezes.

Some good ideas! but unfortunately my setup is pretty boring, single ultrawide (DELL U3818W) monitor running at a paltry 60hz, no forced composition pipeline.

Happy to poke more if anyone thinks of anything though! I have noticed when playing Kingdoms and Castles, which uses Unity, there haven't been any freezes, which is quite weird

[Daniel-McLarty]

Some good ideas! but unfortunately my setup is pretty boring, single ultrawide (DELL U3818W) monitor running at a paltry 60hz, no forced composition pipeline.

Happy to poke more if anyone thinks of anything though! I have noticed when playing Kingdoms and Castles, which uses Unity, there haven't been any freezes, which is quite weird

@gregflynn I seam to get freezes even just on the desktop. Since it does not seam to be tied to anything except NVIDIA cards in general maybe it is a driver thing. I think I saw something about this like three years ago when NVIDIA made a mistake but that was fixed rather quick. I did try switching to compfy(which is based on picom but with animations and more active support) and the problem is still there. So maybe it can be fixed in that fork but for now I just have a hook that unloads the compositor on the start of a wine process then restarts it when wine closes. The freezes on the desktop still happen but they are not as annoying as ones in game.

I really hope the dev or a maintainer looks at this sometime soon.

[ssipos90]

@Daniel-McLarty I had those freezes with those exact configurations, but when I removed the config, wine/proton started working without Picom so now I stop picom before gaming. I read about unredir, but I ended up just setting up a key binding + toggle script for starting/stopping picom.

[Daniel-McLarty]

@ssipos90 That is not really a solution to fix a bug.That is just hiding the mess in the closet and saying you cleaned.

[ssipos90]

@Daniel-McLarty I chimed in that I also used those configs and it's happening to me too.

I also shared my workaround for my use-case, which is a solution to my use case and in case anyone else finds it useful.

[yshui]

unfortunately this is not happening here so there is not much investigation i can do. you can run picom with --log-level=trace until it freezes, upload the logs here, and i will have a look. but no promises i will find anything.

[gregflynn]

unfortunately this is not happening here so there is not much investigation i can do. you can run picom with --log-level=trace until it freezes, upload the logs here, and i will have a look. but no promises i will find anything.

I'll give that another shot, when you say it's not happening for you, can you elaborate on your testing setup? like I'm willing to bet this is NVIDIA specific, but if you aren't able to repro on NVIDIA that would be really interesting.

[yshui]

I am on AMD.

If you suspect it's nvidia, can you check if this also happens on --backend xrender?

[gregflynn]

I am on AMD.

If you suspect it's nvidia, can you check if this also happens on --backend xrender?

Next card will definitely be AMD. I will try switching backend as well. I spent about 30 minutes this morning trying to get it reproduced in Civ 6 with trace logging but couldn't get it to happen. Will try more later

[absolutelynothelix]

can't reproduce. i don't have any games but i've installed the supertuxkart as @scfarley said that it should happen there too and lost a race to a god damn xfce icon 😠 played for 15 minutes without any issues despite the fact that i have an nvidia gpu. i've used the configuration file from the first post.

[Daniel-McLarty]

@absolutelynothelix I have also had it freeze for me on YouTube when watching on LibreWolf. When it comes to games some of the worst were the ones running though DXVK on Proton/Wine while using Ray Tracing like Control. The severity seams to differ on a program by program basis.

Edit: the only common point is that killing picom stops the problem.

[gregflynn]

I was able to reproduce with log-level trace but the output is quite overwhelming, is there a phrase to grep for that would trim the output or is there something in particular I'm looking for?

I'm not able to reproduce with --backend xrender

[absolutelynothelix]

I was able to reproduce with log-level trace but the output is quite overwhelming, is there a phrase to grep for that would trim the output or is there something in particular I'm looking for?

just upload the whole log (as a file) here. also, it would be helpful to know how quickly you stopped picom after the freeze happened to narrow down the area of search.

[yshui]

hmm, i have a theory.

never mind.

[gregflynn]

Ok it should be in this section of logs, this is the last 2MB of the written log, looks to be about the last 2 minutes, i think i killed picom within about 10 seconds. At about 13:49:53 it looks like looks stop right around when i think it hung, and logs start again when the alt-tab i think in the logs at 13:49:59, if I'm reading this correctly

[ 12/22/2023 13:47:53.719 add_damage TRACE ] Adding damage:
[ 12/22/2023 13:47:53.719 dump_region TRACE ] nrects: 3
[ 12/22/2023 13:47:53.719 dump_region TRACE ] (7, 37) - (3833, 38)
[ 12/22/2023 13:47:53.719 dump_region TRACE ] (6, 38) - (3834, 1593)
[ 12/22/2023 13:47:53.719 dump_region TRACE ] (7, 1593) - (3833, 1594)
[ 12/22/2023 13:47:53.719 paint_preprocess TRACE ] Window 0x04400032 ((null)) will not be painted because it is positioned outside of the screen
[ 12/22/2023 13:47:53.719 paint_preprocess TRACE ] Window 0x00800007 (Awesome no input window) will not be painted because it is positioned outside of the screen
[ 12/22/2023 13:47:53.719 paint_preprocess TRACE ] Window 0x00800014 (Awesome drawin) will be painted
[ 12/22/2023 13:47:53.719 paint_preprocess TRACE ] Window 0x008003ca (Sid Meier's Civilization VI (DX11)) will be painted
[ 12/22/2023 13:47:53.719 paint_preprocess TRACE ] Window 0x008000c0 (Alacritty) will be painted
[ 12/22/2023 13:47:53.719 paint_preprocess TRACE ] Window 0x00800326 (Steam) will be painted
[ 12/22/2023 13:47:53.719 draw_callback_impl TRACE ] Render start, frame 58885
[ 12/22/2023 13:47:53.735 draw_callback_impl TRACE ] Render end
[ 12/22/2023 13:47:59.730 ev_handle TRACE ] event     Damage serial 0x00080368 window 0x008003ca "Sid Meier's Civilization VI (DX11)"
[ 12/22/2023 13:47:59.730 repair_win TRACE ] Mark window 0x008003ca (Sid Meier's Civilization VI (DX11)) as having received damage
[ 12/22/2023 13:47:59.730 add_damage TRACE ] Adding damage:
[ 12/22/2023 13:47:59.730 dump_region TRACE ] nrects: 3
[ 12/22/2023 13:47:59.730 dump_region TRACE ] (7, 37) - (3833, 38)
[ 12/22/2023 13:47:59.730 dump_region TRACE ] (6, 38) - (3834, 1593)
[ 12/22/2023 13:47:59.730 dump_region TRACE ] (7, 1593) - (3833, 1594)
[ 12/22/2023 13:47:59.730 ev_handle TRACE ] event     Damage serial 0x00080368 window 0x00800326 "Steam"
[ 12/22/2023 13:47:59.730 repair_win TRACE ] Mark window 0x00800326 (Steam) as having received damage
[ 12/22/2023 13:47:59.730 add_damage TRACE ] Adding damage:
[ 12/22/2023 13:47:59.730 dump_region TRACE ] nrects: 0
[ 12/22/2023 13:47:59.730 ev_handle DEBUG ] event   FocusOut serial 0x00080369 window 0x008003ca "Sid Meier's Civilization VI (DX11)"
[ 12/22/2023 13:47:59.730 ev_focus_out DEBUG ] { mode: NotifyGrab, detail: NotifyVirtual }

picom-tail.log

[Daniel-McLarty]

It seams to be more focused right here:

[ 12/22/2023 13:47:53.735 draw_callback_impl TRACE ] Render end
[ 12/22/2023 13:47:59.730 ev_handle TRACE ] event     Damage serial 0x00080368 window 0x008003ca "Sid Meier's Civilization VI (DX11)"

as it freezes for six seconds right at this point.

[yshui]

That's pretty much what I expected to see. it's not that picom froze for 6 seconds, picom didn't receive any damage events for 6 seconds, so it rightfully thought there is nothing to render.

the mystery is what happened to the missing damage event. Try xtrace. Note its output will be even noisier than --log-level=verbose, try gzipping the result first and upload.

[gregflynn]

Two quick updates:

1. I have experienced the issue at the desktop like @Daniel-McLarty described. Firefox (121.0-1) with two windows playing a video (one on youtube and the other showing an octoprint webcam). I wasn't logging during the occurrence so not much more to go on, just a "me too".

2. I have not been able to get xtrace to do anything but lock up my X11 session (requiring switching tty and kill -9, not responding to SIGQUIT). Maybe I'm reading the manpages wrong but what I tried running was:

xtrace -- /usr/bin/picom --config ~/path/to/picom.conf --log-level=trace

using https://aur.archlinux.org/packages/xtrace since it was faster to get installed than your fork and I didn't think the two commits in the fork were relevant but do please correct me if there's something specific in the fork needed to debug this.

[absolutelynothelix]

we need a volunteer that can catch a juicy freeze (ideally longer than a second) on the glx or egl backends while doing a trace log + xtrace. vanilla xtrace (i.e. not yshui’s) should be fine. the command would be something like rm -f trace.log xtrace.log && x11trace --timestamps picom --log-level=TRACE --log-file=trace.log > xtrace.log. when you hit a freeze, stop picom asap and upload the logs here (hint: tar cfJ traces.tar.xz trace.log xtrace.log). would be perfect if you can catch a freeze quick as both logs grow really fast.

[chardoncs]

I have the same bug since yesterday. I suspect it's Picom v11.
Yesterday was RDR2 on Proton 8. Today I found it happens when I watch youtube videos on Firefox.

Btw my GPU is nvidia.

[Daniel-McLarty]

It still seams to happen with GLX back end and vsync both on and off, I have tried all backend and vsync combos to no change. Though it seams to be most minimal with GLX backend and vsync on, but it still happens.

[chardoncs]

I'll try GLX. It happens for me with xrender and the interval seems completely random.

Update: Just tried. I think the issue is mitigated in GLX backend, since I did not meet with that for now.

[yshui]

I forgot to ask: when did this start happening? Was picom working properly at some point in the past, and only broke after you updated some packages?

[chardoncs]

the xrender case specifically is tracked in #1166, @chardon55. we know which commit made it more likely to happen for xrender. we don't know the root cause yet.

if i know when this started to happen on glx, it might give us some hints what is causing it.

Thank you.

[awused]

This is potentially the same issue as my old bug report from March, #1040, does it still reproduce with --legacy-backend and the same config files?

In my case it started when the default backend switch happened, which doesn't help narrow down the specific commits.

[Daniel-McLarty]

Idea, why cant we just make picom send a faked damage event to itself at the refresh rate of the monitor if it does not get one for say 5-10 frame times? It is more of a workaround then a fix, but it could at least be a temp fix while we find the problem. You could also put it behind a flag in the config so it does not potentially bog down hardware configs without the problem.

Maybe a nvidia-experimental-fix = true in the config could trigger the "fix" I just listed.

[gregflynn]

Idea, why cant we just make picom send a faked damage event to itself at the refresh rate of the monitor if it does not get one for say 5-10 frame times? It is more of a workaround then a fix, but it could at least be a temp fix while we find the problem. You could also put it behind a flag in the config so it does not potentially bog down hardware configs without the problem.

Maybe a nvidia-experimental-fix = true in the config could trigger the "fix" I just listed.

Sorry I haven't been able to commit time to debugging further as I've had other priorities and removed picom from my setup for the time being. @Daniel-McLarty or @chardon55 can you attempt to reproduce with the xtrace running as described in @absolutelynothelix 's comment? Devoting @yshui 's time for such a wild workaround when simpler debugging avenues haven't been fully explored isn't the best use of development time.

[chardoncs]

Sorry I haven't been able to commit time to debugging further as I've had other priorities and removed picom from my setup for the time being. @Daniel-McLarty or @chardon55 can you attempt to reproduce with the xtrace running as described in @absolutelynothelix 's comment? Devoting @yshui 's time for such a wild workaround when simpler debugging avenues haven't been fully explored isn't the best use of development time.

I'll try it some day. But GLX currently seems fine for me, I have no idea whether I can reproduce it.

[yshui]

Please give #1181 a try, see if that fix your freezes

[yshui]

has anyone here had a chance to try #1181?

@seiuneko any luck getting the trace/xtrace logs?

[seiuneko]

@yshui Sorry, there have been no instances of freezing since February 7, 2024. The version of picom currently running is v11.1.

[Daniel-McLarty]

has anyone here had a chance to try #1181?

@seiuneko any luck getting the trace/xtrace logs?

I am going to try logging today, I would try the patch but I'm on NixOS and still new to it and how to compile binaries in the Nix Store

[yshui]

@Daniel-McLarty

I'm on NixOS and still new to it

Oh, this makes things way easier, just do:

nix run github:yshui/picom/defroster

[yshui]

@seiuneko do you mean there are no freezes with #1181 applied? or are you running vanilla v11.1?

[seiuneko]

@yshui I'm running vanilla v11.1.

[Daniel-McLarty]

@Daniel-McLarty

I'm on NixOS and still new to it

Oh, this makes things way easier, just do:

nix run github:yshui/picom/defroster

Will I get a verbose output or anything like that and is this the patched code?

[Daniel-McLarty]

@yshui
Dont know if this means anything, but after running this for about 30 minutes in a game I got no pauses but these logs in the terminal.

[ 02/09/2024 19:19:02.763 x_log_error WARN ] X error 3 WINDOW request 2 minor 0 serial 58511
[ 02/09/2024 19:19:05.885 x_log_error WARN ] X error 3 WINDOW request 2 minor 0 serial 61858
[ 02/09/2024 19:19:08.834 x_log_error WARN ] X error 3 WINDOW request 2 minor 0 serial 66116
[ 02/09/2024 19:44:38.640 x_log_error WARN ] X error 3 WINDOW request 2 minor 0 serial 1665337

[yshui]

@Daniel-McLarty

Will I get a verbose output or anything like that and is this the patched code?

you can pass arguments to nix run like this nix run github:yshui/picom/defroster -- --log-level=verbose. this nix run command means "run picom from the defroster branch", so yes, it has the patch.

I got no pauses

good news then.

[Daniel-McLarty]

@yshui thanks man, that patch seams to work if you wanna put it in main, no freezes since I activated it.

[gregflynn]

Please give #1181 a try, see if that fix your freezes

Ran it for a few hours, can't reproduce the freezes 🥳

[absolutelynothelix]

@Daniel-McLarty,

[ 02/09/2024 19:19:02.763 x_log_error WARN ] X error 3 WINDOW request 2 minor 0 serial 58511
[ 02/09/2024 19:19:05.885 x_log_error WARN ] X error 3 WINDOW request 2 minor 0 serial 61858
[ 02/09/2024 19:19:08.834 x_log_error WARN ] X error 3 WINDOW request 2 minor 0 serial 66116
[ 02/09/2024 19:44:38.640 x_log_error WARN ] X error 3 WINDOW request 2 minor 0 serial 1665337

if you get such warnings when closing windows in xfce they're harmless.

[Daniel-McLarty]

Wondering, should I open an issue with the Nix team so NixOS can get this patch, or is that a job for the maintainer of it on the Nix side/the job of someone on the Picom team? Don't wanna steep on toes, also I am not sure of the exacts of releases and the like, does the merge count as a release or is it still too early. Still new to most of this and I don't want to be a bother.