Public bug reported: On Ubuntu 26.04.1 Wayland, rubber-band selection on the actual desktop causes severe stutter, including the mouse pointer and general shell responsiveness. The problem survives installing the current Ubuntu GNOME/NVIDIA/kernel updates and rebooting. Ordinary test-window animation and movement look smooth, so desktop selection is the important reproducer.
Reproduction 1. Log into the Ubuntu Wayland session with the packaged Desktop Icons NG (DING) enabled and its default GTK 3 rendering path. 2. Use the 3840x2160, 60 Hz display at 125% scaling. 3. Left-click empty desktop space and continuously drag a selection rectangle, changing its size and direction. 4. Observe the rectangle and pointer stuttering together. This reproduces shortly after reboot; long session uptime is not required. Expected: selecting desktop icons should not stall the pointer or the whole shell. Actual: desktop updates block for tens to approximately 150 ms, with high GNOME Shell CPU usage on one logical CPU. Environment after updating and rebooting - Ubuntu 26.04.1, GNOME Wayland - gnome-shell 50.1-0ubuntu1.4 - mutter/libmutter-18-0 50.1-0ubuntu2.4 - gnome-shell-ubuntu-extensions 50.26.04.8ubuntu (packaged GTK 3 DING) - libgtk-3-0t64 3.24.52-0ubuntu1 - NVIDIA open driver 595.99.02, two RTX 3090 GPUs; HDMI display attached to the second GPU - Linux 7.0.0-38-generic - Two Xeon Gold 6240R CPUs, 96 logical CPUs, approximately 184 GiB RAM - Samsung 43-inch display, 3840x2160 at 60 Hz, scale 1.25, logical desktop 3072x1728 The problem was also present before updating, with gnome-shell 50.1-0ubuntu1.2, NVIDIA 595.91.07 and kernel 7.0.0-34. Mutter and the Ubuntu extensions package did not change during that update. Measurements A. Before updating, during a user-confirmed reproduction on the actual desktop: - GNOME Shell average CPU: 81.41%; DING: 10.88% (100% = one logical CPU). - Sysprof: 456 Meta::WaylandSurface::commit() marks over approximately 22 seconds, cumulative duration approximately 16.69 seconds. - Commit duration p95 147.146 ms; maximum 150.004 ms. - Atomic page-flip callback interval p95 150.006 ms; maximum 150.077 ms. - Clutter frame-dispatch maximum 1.316 ms; libinput dispatch maximum approximately 0.2 ms in that capture. B. After updating and rebooting, during another actual desktop drag: - perf record with cycles:u, 99 Hz, DWARF call-graph capture, approximately 22 seconds; 1,913 samples, no lost samples. - Approximately 98.3% of event-weighted profile overhead was in one small loop in dynamically generated GL code backed by a deleted .glXXXXXX mapping in gnome-shell. - Inspection of that executable code showed a scalar loop reading 32-bit pixels, swapping the red/blue bytes, retaining green/alpha, and writing them back. - The exact NVIDIA internal function name and full caller chain were not resolved. This is evidence of expensive pixel-channel conversion in the compositor's GL path, not proof of which project's code needs fixing. - DING had an approximately 81 MiB gdk-wayland shared-memory mapping in its normal rendering mode. Working local workaround Force GDK_GL=always only in the DING process, before GTK initialization. For the trusted shell-managed desktop process, I tested this by inserting the following line immediately after 'use strict'; in /usr/share/gnome-shell/extensions/[email protected]/app/ding.js: imports.gi.GLib.setenv('GDK_GL', 'always', true); Then restart only the DING extension: gnome-extensions disable [email protected] gnome-extensions enable [email protected] The desktop user confirmed that the result was clearly smoother. After restoring the original file, the same option was applied as a local workaround and DING was restarted again. The new DING process loads NVIDIA EGL libraries and no longer has the gdk-wayland shared-memory mapping observed before. In an additional profile with this option, the heavy dynamic GL conversion samples were concentrated in DING/gjs rather than gnome- shell. The workaround appears to move the expensive conversion out of the compositor's critical path; it does not establish that the conversion cost disappears or that DING renders at a stable 60 FPS. A subsequent approximately 22-second Sysprof capture recorded 710 commit marks with p95 0.050 ms and maximum 0.118 ms. Manual drag timing and speed were not controlled across captures, so these values should not be interpreted as a matched performance improvement ratio. CPU averages from the later captures are omitted for the same reason. The original DING package files passed dpkg -V before any workaround. The only persistent local package modification now is the single environment-setting line described above. The failure and baseline measurements predate that modification. The workaround has not been validated across a further reboot. Other checks - 100% scaling reduced commit duration (p95 46.759 ms, maximum 54.935 ms) but did not remove the problem; 125% was restored. - Disabling Ubuntu Dock and Tiling Assistant while retaining DING did not remove the high shell CPU usage. - Temporarily maintaining high GPU clocks did not solve it. That experiment added a small CUDA workload, so it is not a clean comparison of clock speed alone. - Approximately 7 GiB RAM used, no swap use, no CPU/GPU overheating, and no relevant NVIDIA Xid/MCE errors found in the inspected kernel logs. - A standalone copy of DING and an ordinary animation test did not reproduce the same compositor stall. Please use the real shell-managed desktop surface for reproduction. Triage request Please investigate the DING GTK 3 shared-memory buffer update / Mutter GL upload interaction on NVIDIA, including pixel format conversion and compositor-thread blocking. I am initially filing against mutter because the observed long stall is in its surface-commit path, but this may need reassignment or additional tasks for gnome-shell-ubuntu-extensions, GTK, or the NVIDIA driver. Related reports (similar mechanisms, not established duplicates) - https://github.com/niri-wm/niri/issues/4605 : large NVIDIA wl_shm imports stall animations; closed as a duplicate of #1445, not as a confirmed fix. - https://github.com/niri-wm/niri/issues/1445 : maintainers identify large GTK 3 shm updates; waiting on Smithay changes. This is a different compositor. - https://zamundaaa.github.io/wayland/2026/05/06/making-wl-shm-fast.html : KWin developer explains how synchronous shm texture uploads block compositor responsiveness. KWin's changes are not a Mutter fix. - https://bugs.launchpad.net/bugs/2171024 : the separately reported cursor-surface leak has not been established as the cause here; this desktop-drag problem reproduces soon after reboot. This report contains technical summaries only. Raw perf/Sysprof captures, process memory, personal paths, identifiers and unrelated logs have not been attached. ** Affects: mutter (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2171567 Title: [NVIDIA/Wayland] Desktop selection drag stalls GNOME Shell; GDK_GL=always in DING improves responsiveness To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2171567/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
