Weird behavior with --experimental-backends after #716 PR was merged

[lombervid]

Platform

• Linux Arch 5.14.16-arch1-1

GPU, drivers, and screen setup

• I use a Nvidia GTX 970, but I'm on VMware
• f86-video-vmware 13.3.0-2
• mesa 21.2.4-1

glxinfo -B

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: VMware, Inc. (0x15ad)
    Device: SVGA3D; build: RELEASE;  LLVM; (0x405)
    Version: 21.2.4
    Accelerated: no
    Video memory: 1MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.1
    Max compat profile version: 4.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: SVGA3D; build: RELEASE;  LLVM;
OpenGL core profile version string: 4.1 (Core Profile) Mesa 21.2.4 #
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.1 (Compatibility Profile) Mesa 21.2.4
OpenGL shading language version string: 4.10
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 21.2.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

Environment

• bspwm

picom version

• vgit-655570

Diagnostics

[ 11/09/2021 17:10:20.852 get_cfg WARN ] Dual-kawase blur is not implemented by the legacy backends, you must use the `experimental-backends` option.
[ 11/09/2021 17:10:20.936 init_render WARN ] Old backends only support blur method "kernel". Your blur setting will not be applied
**Version:** vgit-655570

### Extensions:

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

### Misc:

* Use Overlay: No
  (Another compositor is already running)
* Config file used: /home/lombervid/.config/picom/picom.conf

### Drivers (inaccurate):



### Backend: glx

* Driver vendors:
 * GLX: Mesa Project and SGI
 * GL: VMware, Inc.
* GL renderer: SVGA3D; build: RELEASE;  LLVM;
* Accelerated: 0

(You are using a software renderer. Unless you are doing this
intentionally, this means you don't have a graphics driver
properly installed. Performance will suffer. Please fix this
before reporting your issue.)

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.028
fade-in-step = 0.03;

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

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

# Specify a list of conditions of windows that should not be faded.
# fade-exclude = []

# Do not fade on window open/close.
# no-fading-openclose = false

# Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc.
# no-fading-destroyed-argb = false


#################################
#   Transparency / Opacity      #
#################################


# Opacity of inactive windows. (0.1 - 1.0, defaults to 1.0)
# inactive-opacity = 1
inactive-opacity = 0.8;

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

# Let inactive opacity set by -i override the '_NET_WM_OPACITY' values of windows.
# inactive-opacity-override = true
inactive-opacity-override = false;

# Default opacity for active windows. (0.0 - 1.0, defaults to 1.0)
# active-opacity = 1.0

# Dim inactive windows. (0.0 - 1.0, defaults to 0.0)
# inactive-dim = 0.0

# Specify a list of conditions of windows that should 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 = 8

# Exclude conditions for rounded corners.
rounded-corners-exclude = [
  "window_type = 'dock'",
  "window_type = 'desktop'",
  "class_g = 'polybar'",
  "class_g = 'firefox'"
];


#################################
#     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-method = "dual_kawase"
blur-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'",
  "_GTK_FRAME_EXTENTS@:c"
];

#################################
#       General Settings        #
#################################

# Daemonize process. Fork to background after initialization. Causes issues with certain (badly-written) drivers.
# daemon = false

# Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`.
# `xrender` is the default one.
#
# backend = "xrender";
backend = "glx"

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

# Enable remote control via D-Bus. See the *D-BUS API* section below for more details.
# dbus = false

# Try to detect WM windows (a non-override-redirect window with no
# child that has 'WM_STATE') and mark them as active.
#
# mark-wmwin-focused = false
mark-wmwin-focused = true;

# Mark override-redirect windows that doesn't have a child window with 'WM_STATE' focused.
# mark-ovredir-focused = false
mark-ovredir-focused = true;

# Try to detect windows with rounded corners and don't consider them
# shaped windows. The accuracy is not very high, unfortunately.
#
# detect-rounded-corners = false
detect-rounded-corners = true;

# Detect '_NET_WM_OPACITY' on client windows, useful for window managers
# not passing '_NET_WM_OPACITY' of client windows to frame windows.
#
# detect-client-opacity = false
detect-client-opacity = true;

# Specify refresh rate of the screen. If not specified or 0, picom will
# try detecting this with X RandR extension.
#
# refresh-rate = 60
refresh-rate = 0;

# 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 everytime, instead of the part of the screen
# has actually changed. Potentially degrades the performance, but might fix some artifacts.
# The opposing option is use-damage
#
# no-use-damage = false
use-damage = true;

# Use X Sync fence to sync clients' draw calls, to make sure all draw
# calls are finished before picom starts drawing. Needed on nvidia-drivers
# with GLX backend for some users.
#
# xrender-sync-fence = false

# GLX backend: Use specified GLSL fragment shader for rendering window contents.
# See `compton-default-fshader-win.glsl` and `compton-fake-transparency-fshader-win.glsl`
# in the source tree for examples.
#
# glx-fshader-win = ""

# Force all windows to be painted with blending. Useful if you
# have a glx-fshader-win that could turn opaque pixels transparent.
#
# force-win-blend = false

# Do not use EWMH to detect fullscreen windows.
# Reverts to checking if a window is fullscreen based only on its size and coordinates.
#
# no-ewmh-fullscreen = false

# Dimming bright windows so their brightness doesn't exceed this set value.
# Brightness of a window is estimated by averaging all pixels in the window,
# so this could comes with a performance hit.
# Setting this to 1.0 disables this behaviour. Requires --use-damage to be disabled. (default: 1.0)
#
# max-brightness = 1.0

# Make transparent windows clip other windows like non-transparent windows do,
# instead of blending on top of them.
#
# transparent-clipping = false

# Set the log level. Possible values are:
#  "trace", "debug", "info", "warn", "error"
# in increasing level of importance. Case doesn't matter.
# If using the "TRACE" log level, it's better to log into a file
# using *--log-file*, since it can generate a huge stream of logs.
#
# log-level = "debug"
log-level = "warn";

# Set the log file.
# If *--log-file* is never specified, logs will be written to stderr.
# Otherwise, logs will to written to the given file, though some of the early
# logs might still be written to the stderr.
# When setting this option from the config file, it is recommended to use an absolute path.
#
# log-file = "/path/to/your/log/file"

# Show all X errors (for debugging)
# show-all-xerrors = false

# Write process ID to a file.
# write-pid-path = "/path/to/your/log/file"

# Window type settings
#
# 'WINDOW_TYPE' is one of the 15 window types defined in EWMH standard:
#     "unknown", "desktop", "dock", "toolbar", "menu", "utility",
#     "splash", "dialog", "normal", "dropdown_menu", "popup_menu",
#     "tooltip", "notification", "combo", and "dnd".
#
# Following per window-type options are available: ::
#
#   fade, shadow:::
#     Controls window-type-specific shadow and fade settings.
#
#   opacity:::
#     Controls default opacity of the window type.
#
#   focus:::
#     Controls whether the window of this type is to be always considered focused.
#     (By default, all window types except "normal" and "dialog" has this on.)
#
#   full-shadow:::
#     Controls whether shadow is drawn under the parts of the window that you
#     normally won't be able to see. Useful when the window has parts of it
#     transparent, and you want shadows in those areas.
#
#   clip-shadow-above:::
#     Controls wether 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 = 0.75; focus = true; full-shadow = false; };
  dock = { shadow = false; clip-shadow-above = true; }
  dnd = { shadow = false; }
  popup_menu = { opacity = 0.8; }
  dropdown_menu = { opacity = 0.8; }
};

Steps of reproduction

1. Enter the WM
2. Open any app

Expected behavior

• Brightness level remains to the same level.

Current Behavior

• Brightness increases considerably.
• Also, I've noticed that the wallpaper doesn't cover the full screen.

Other details

Also, I just realized those warnings about the backend in the diagnostics, but, as you can see in the video, I'm already using the --experimental-backends option.

This behavior started to happen after the #716 was merged.

Regards!

https://user-images.githubusercontent.com/3432651/141026910-851cd04d-c7bc-4a02-bce3-e5cda93b85b9.mp4

[yshui]

Could be a bug of use-damage = true. Does the problem go away if you disable that?

[lombervid]

No, the same behavior keeps happening.

[lombervid]

I have been trying with different commits, and after this one is when it starts to happen: ffb8bc5

[yshui]

That's odd as you are not even using the xrender backend

[lombervid]

Yes, I also thought that.

Btw, I just realized I can't even use xrender. I got this message:

[yshui]

Hmm, can't reproduce that. Can you try build with address sanitizer?

[lombervid]

Not sure if I did it correctly. Is it doing it this way?

If so, this is what I got:

picom --experimental-backends --backend xrender

=================================================================
==7562==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6060000030b8 at pc 0x5574e6b2a059 bp 0x7ffe934ffcd0 sp 0x7ffe934ffcc0
READ of size 4 at 0x6060000030b8 thread T0
    #0 0x5574e6b2a058  (/usr/bin/picom+0xa2058)
    #1 0x5574e6b2e4ec  (/usr/bin/picom+0xa64ec)
    #2 0x5574e6abfd81  (/usr/bin/picom+0x37d81)
    #3 0x5574e6abfadb  (/usr/bin/picom+0x37adb)
    #4 0x5574e6ac28dd  (/usr/bin/picom+0x3a8dd)
    #5 0x7f1f40af6032 in ev_invoke_pending (/usr/lib/libev.so.4+0x5032)
    #6 0x7f1f40af9901 in ev_run (/usr/lib/libev.so.4+0x8901)
    #7 0x5574e6ab5936  (/usr/bin/picom+0x2d936)
    #8 0x7f1f40537b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #9 0x5574e6aba31d  (/usr/bin/picom+0x3231d)

0x6060000030b8 is located 0 bytes to the right of 56-byte region [0x606000003080,0x6060000030b8)
allocated by thread T0 here:
    #0 0x7f1f40cfe459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x5574e6b230c0  (/usr/bin/picom+0x9b0c0)
    #2 0x5574e6b2e2d5  (/usr/bin/picom+0xa62d5)
    #3 0x5574e6abfd81  (/usr/bin/picom+0x37d81)
    #4 0x5574e6abfadb  (/usr/bin/picom+0x37adb)
    #5 0x5574e6ac28dd  (/usr/bin/picom+0x3a8dd)
    #6 0x7f1f40af6032 in ev_invoke_pending (/usr/lib/libev.so.4+0x5032)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/bin/picom+0xa2058) 
Shadow bytes around the buggy address:
  0x0c0c7fff85c0: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c0c7fff85d0: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
  0x0c0c7fff85e0: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
  0x0c0c7fff85f0: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c0c7fff8600: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa
=>0x0c0c7fff8610: 00 00 00 00 00 00 00[fa]fa fa fa fa fd fd fd fd
  0x0c0c7fff8620: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8650: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8660: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==7562==ABORTING

[yshui]

Thanks. But you want to use --buildtype=debug, otherwise the stack trace won't be very useful.

[lombervid]

Ok. This is what I get now:

=================================================================
==16216==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x606000002db8 at pc 0x558a38566374 bp 0x7ffe0b0a90d0 sp 0x7ffe0b0a90c0
READ of size 4 at 0x606000002db8 thread T0
    #0 0x558a38566373 in compose_impl ../src/backend/xrender/xrender.c:188
    #1 0x558a38567c0a in compose ../src/backend/xrender/xrender.c:289
    #2 0x558a3857a12e in paint_all_new ../src/backend/backend.c:404
    #3 0x558a384d62bf in draw_callback_impl ../src/picom.c:1542
    #4 0x558a384d5f9c in draw_callback_impl ../src/picom.c:1525
    #5 0x558a384d6542 in draw_callback ../src/picom.c:1569
    #6 0x7f3016604032 in ev_invoke_pending (/usr/lib/libev.so.4+0x5032)
    #7 0x7f3016607901 in ev_run (/usr/lib/libev.so.4+0x8901)
    #8 0x558a384df79d in session_run ../src/picom.c:2445
    #9 0x558a384dff6c in main ../src/picom.c:2547
    #10 0x7f3016062b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #11 0x558a384c7d5d in _start (/home/lombervid/projects/github/picom/build/src/picom+0x3bd5d)

0x606000002db8 is located 0 bytes to the right of 56-byte region [0x606000002d80,0x606000002db8)
allocated by thread T0 here:
    #0 0x7f301680c459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x558a38563d70 in default_clone_image ../src/backend/backend_common.c:431
    #2 0x558a38579dfe in paint_all_new ../src/backend/backend.c:397
    #3 0x558a384d62bf in draw_callback_impl ../src/picom.c:1542
    #4 0x558a384d5f9c in draw_callback_impl ../src/picom.c:1525
    #5 0x558a384d6542 in draw_callback ../src/picom.c:1569
    #6 0x7f3016604032 in ev_invoke_pending (/usr/lib/libev.so.4+0x5032)

SUMMARY: AddressSanitizer: heap-buffer-overflow ../src/backend/xrender/xrender.c:188 in compose_impl
Shadow bytes around the buggy address:
  0x0c0c7fff8560: 00 00 04 fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c0c7fff8570: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
  0x0c0c7fff8580: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
  0x0c0c7fff8590: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c0c7fff85a0: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
=>0x0c0c7fff85b0: 00 00 00 00 00 00 00[fa]fa fa fa fa fd fd fd fd
  0x0c0c7fff85c0: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff85d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff85e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff85f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==16216==ABORTING

[yshui]

Thanks for the report! It has been fixed in the next branch. Although this is probably not related to the original bug.

[lombervid]

Thank you! And yeah, I'm still getting the same behavior.

[yshui]

Can you grab a trace, with the glx backend?

[lombervid]

Sure, here is what I got:

picom.trace.tar.gz

Let me know if there is something wrong and/or something I need to do in order to get better information.

[yshui]

From your trace it looks like the bright/"overexposed" window comes straight from kitty itself. picom is rendering that window correctly. maybe kitty is doing something weird?

[lombervid]

I'm not sure. But that happens basically with any app, not only kitty:

https://user-images.githubusercontent.com/3432651/143318484-20112b7b-0571-4710-8154-a654c1babe37.mp4

picom_0.trace.tar.gz picom_1.trace.tar.gz picom_2.trace.tar.gz picom_3.trace.tar.gz

And it worked fine in older versions:

https://user-images.githubusercontent.com/3432651/143318653-39baa715-4a53-4013-8e06-dfde9849e83d.mp4

[yshui]

When you say this starts to happen after ffb8bc5b29c3cf40cdb5578886d11dcbfd59a74e, did you mean you did a git bisect? If you didn't, can you please do that?

[yshui]

Does this happen outside of VMware too? Can you try running picom on host side if you were able to.

[lombervid]

When you say this starts to happen after ffb8bc5, did you mean you did a git bisect? If you didn't, can you please do that?

I just did manual checkouts from 6555703 to fade045.

This is doing a bisect from 31e5871 to 06c58d0:

1fec938740149924e66e799e97dba108c7a3f5cf is the first bad commit
commit 1fec938740149924e66e799e97dba108c7a3f5cf
Author: Yuxuan Shui <[email protected]>
Date:   Sat Jul 17 00:01:09 2021 +0100

    backend: gl_common: handle corner radius property
    
    Signed-off-by: Yuxuan Shui <[email protected]>

 src/backend/gl/gl_common.c | 18 ++++++++++++++++++
 src/backend/gl/gl_common.h |  1 +
 2 files changed, 19 insertions(+)

git bisect log

# bad: [31e58712ec11b198340ae217d33a73d8ac73b7fe] Use python3 for tests
# good: [06c58d0b8e49e8d6101a5daba5bd23e779c9eac1] render: avoid left shifting negative values
git bisect start 'HEAD' 'vNext' '--'
# good: [049d347f5222dc563964171680020eb639500b5c] Merge pull request #648 from tryone144/fix-pixmap-texture-nvidia
git bisect good 049d347f5222dc563964171680020eb639500b5c
# good: [4f817c452d3cb1605696a6c19a72036c28113574] Merge pull request #694 from jpribyl/patch-1
git bisect good 4f817c452d3cb1605696a6c19a72036c28113574
# good: [fade045eadf171d2c732820d6ebde7d1943a1397] Merge pull request #708 from TK009/next
git bisect good fade045eadf171d2c732820d6ebde7d1943a1397
# bad: [1dea294051e4ba7aa2746b071ee2f64f68f520c5] backend: xrender: cache rounded rectangle mask
git bisect bad 1dea294051e4ba7aa2746b071ee2f64f68f520c5
# bad: [6d72bf2974384edafa6cb298e7df9bfc0125af2a] options: don't disable rounded corner for new backends
git bisect bad 6d72bf2974384edafa6cb298e7df9bfc0125af2a
# bad: [1fec938740149924e66e799e97dba108c7a3f5cf] backend: gl_common: handle corner radius property
git bisect bad 1fec938740149924e66e799e97dba108c7a3f5cf
# good: [de31cd40960a527aa6f8c42694d9c0fe8d3f1fbf] backend: add new image property: corner radius
git bisect good de31cd40960a527aa6f8c42694d9c0fe8d3f1fbf
# first bad commit: [1fec938740149924e66e799e97dba108c7a3f5cf] backend: gl_common: handle corner radius property

According to this, 1fec938 is the first commit where it behaves that way. But it is weird, since, as you can see in the last video from my previous comment, fade045 seems to work fine.

Does this happen outside of VMware too? Can you try running picom on host side if you were able to.

Unfortunately, I can't. Since my host is Windows. I will check if I can use a SSD from an old computer to test there, but no promises.

[tryone144]

https://github.com/yshui/picom/commit/1fec938740149924e66e799e97dba108c7a3f5cf is part of #716 you mentioned in your original post. This commit isn't present in your tree when checking out https://github.com/yshui/picom/commit/fade045eadf171d2c732820d6ebde7d1943a1397.

https://github.com/yshui/picom/commit/1fec938740149924e66e799e97dba108c7a3f5cf added the rounded corners to the gl backend. A change there can be a plausible cause for the behaviour you are witnessing. The issue looks similar to color multiplication with values larger than 1, but I am not sure, what exactly is going wrong in this case.

[yshui]

I am thinking this could be a VMware driver issue. Would be nice if we could find out if this happens outside VMware.

Just by looking at the GLSL change I can't see anything wrong.

[lombervid]

Well, I have been testing in a physical hardware and it seems to work fine.

[yshui]

@lombervid Do you have the same WM setup and everything? If so, it's probably a VMware driver bug..

[lombervid]

Yeah, I tried to set it up as close as possible.

I have been testing with the VM and I realized that the problem seems to be that every time a window is rendered, an image of the window remains there even after the window is closed.

https://user-images.githubusercontent.com/3432651/143798843-49e4fb0f-4d55-4fc5-b119-bc1b28d575ac.mp4

[rbreaves]

Same issue here on vmware workstation 16 / player and Ubuntu Mate 22.04. I compiled the latest master and next branch same issue.

Just switched from dual_kawase to gaussian and same issue of the image becoming over exposed.

Also I just checked out the commit just before https://github.com/yshui/picom/commit/1fec938740149924e66e799e97dba108c7a3f5cf - and the issue still persists. Even if no blur is specified it just can't run with glx without the bug.

[GnikDroy]

I do not have this issue anymore.

I suspect it is fixed in the latest mesa driver (22.1.7-1 -> 22.2.1-1)

@rbreaves @lombervid, can you confirm?

[lombervid]

I do not have this issue anymore.

I suspect it is fixed in the latest mesa driver (22.1.7-1 -> 22.2.1-1)

@rbreaves @lombervid, can you confirm?

Hello. Sorry for the late reply.

I have updated the system and I did some testing. And, yeah, I can confirm, at least for me, it seems to be working well now. 👍

[yshui]

Thanks for confirming!