Wayland: crash when resizing secondary window and GNOME desktop has fractional scaling #103000
Operating system: Ubuntu 22.04
Graphics card: Radeon 6800XT
Broken: 3.4.0, branch: blender-v3.4-release, commit date: 2022-12-06 18:46, hash:
a95bf1ac01, type: release
Worked: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash:
b292cfe5a9, type: release
Short description of error
When performing a window resize operation by dragging the bottom right corner of a secondary Blender window (e.g. Window -> New Window) with the corner resize mouse cursor so that window width and height are changed at the same time, Blender has a high chance of crashing, i.e. repeating the resize operation multiple times will lead to a crash, sometimes already on the first resize.
Also the resize operation is really slow, taking around one second for the resized window to render after releasing the mouse button. When setting display scaling to 100%, I could no longer crash Blender but the resize operation was still very slow.
This is running under a vanilla Ubuntu GNOME session with GNOME 42.5. Display server is Wayland with 125% fractional scaling. Screen resolution is 5120x2160 pixels.
This was never an issue with Blender 3.3.1.
Exact steps for others to reproduce the error
- Log in to a vanilla GNOME desktop session using Wayland under Ubuntu 22.04
- Under GNOME settings -> Displays turn on "Fractional scaling" and set the scaling value to 125%
- Launch Blender 3.4.0
- Open a secondary window with Window -> New Window
- Resize the window by dragging the bottom right corner resize window handle
- Repeat 5. until Blender crashes
I'm unable to redo this in gnome-shell 43.1. although resizing does seem to be unreasonably slow.
Fractional scaling is an experimental feature in gnome, I needed to run:
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"
... then restart gnome-shell to access fractional scaling.
Otherwise Blender's Wayland support should work well as I used fractional-scaling during most of it's development with the "river" wl-roots based compositor (with each monitor set to a different scale at times).
As discovered in #102997, it is libdecor which is causing the performance issue. An open bug ticket exists for this under https://gitlab.freedesktop.org/libdecor/libdecor/-/issues/37 . On vanilla Ubuntu 22.04, when I install package
libdecor-tests and then run
libdecor-demo, I can reproduce these slow resizes. On a display with ~5kx2k resolution (with and without fractional scaling enabled), resizing this demo window to roughly more than half of my screen, the window resize repaints start taking around one second each, with some even taking 15 seconds to complete a single repaint.
Now for Blender, these long hangs appear to trigger the crashes for me most of the time in two ways:
- While waiting for the repaint to render after triggering a resize by dragging the bottom right Blender window corner, I release the mouse button and then scroll the mouse wheel with the cursor within the Blender window area
- While waiting for the repaint to render, I keep quickly dragging the window corner even though the Blender window has not updated yet
In both cases, Blender crashes and the following output appears on the shell where I started Blender:
GHOST/Wayland: Error sending request: Broken pipe The Wayland connection broke. Did the Wayland compositor die? Error: Not freed memory blocks: 95670, total unfreed memory 22.589180 MB Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom. Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom. blender: ../external_epoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed. Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom. Aborted (core dumped)
I assume comment https://gitlab.freedesktop.org/libdecor/libdecor/-/issues/37#note_1656985 ff. point towards the underlying issue causing this crash.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?