Problem
On Windows, the AdwOverlaySplitView sidebar expand/collapse animation runs at roughly 30 Hz — noticeably choppy compared to the same animation on Linux. Meanwhile, menu transitions (e.g., switching pen tool pages in the GtkStack) run perfectly smooth at 60 Hz+ on the same machine.
Root Cause
When the GSK renderer is cairo (CPU) — which appears to be the default fallback on Windows under MSYS2/UCRT64 — layout-triggering animations become a bottleneck. The sidebar subtree (a GtkListView, a GtkGrid, multiple AdwPreferencesGroup rows, etc.) gets re-laid-out every frame, and the CPU rasterizer can't keep up at 60 Hz.
The pen page GtkStack slide animation, by contrast, is purely a compositor operation — zero layout work per frame — so it stays fast even with cairo.
Why cairo is the default on Windows
GTK 4.18 removed the old GL renderer. On Windows (via MSYS2/UCRT64), the ngl (OpenGL) renderer doesn't seem to initialize successfully — it falls back silently to cairo. This is likely the same underlying issue that caused the crashes reported in #1061, which led to GSK_RENDERER=gl being hardcoded in 7e1b386. That workaround was later removed in 58aa663 when upgrading to GTK 4.18, leaving the app with no renderer hint on Windows.
Verification
Setting GSK_RENDERER=vulkan makes the sidebar animation instantly smooth at 60 Hz. Users can test this without recompiling:
GSK_RENDERER=vulkan rnote.exe
If Vulkan is unavailable on a given system, GTK will silently fall back to the next available renderer — no crash risk.
Environment
- OS: Windows 11 (MSYS2 / UCRT64 build)
- GTK: 4.18 (via
gtk4 crate 0.10.0)
- libadwaita: 1.7 (via
adw crate 0.8.0)
- Renderers tested: cairo (choppy), ngl (choppy), vulkan (smooth)
Problem
On Windows, the
AdwOverlaySplitViewsidebar expand/collapse animation runs at roughly 30 Hz — noticeably choppy compared to the same animation on Linux. Meanwhile, menu transitions (e.g., switching pen tool pages in theGtkStack) run perfectly smooth at 60 Hz+ on the same machine.Root Cause
When the GSK renderer is cairo (CPU) — which appears to be the default fallback on Windows under MSYS2/UCRT64 — layout-triggering animations become a bottleneck. The sidebar subtree (a
GtkListView, aGtkGrid, multipleAdwPreferencesGrouprows, etc.) gets re-laid-out every frame, and the CPU rasterizer can't keep up at 60 Hz.The pen page
GtkStackslide animation, by contrast, is purely a compositor operation — zero layout work per frame — so it stays fast even with cairo.Why cairo is the default on Windows
GTK 4.18 removed the old GL renderer. On Windows (via MSYS2/UCRT64), the ngl (OpenGL) renderer doesn't seem to initialize successfully — it falls back silently to cairo. This is likely the same underlying issue that caused the crashes reported in #1061, which led to
GSK_RENDERER=glbeing hardcoded in 7e1b386. That workaround was later removed in 58aa663 when upgrading to GTK 4.18, leaving the app with no renderer hint on Windows.Verification
Setting
GSK_RENDERER=vulkanmakes the sidebar animation instantly smooth at 60 Hz. Users can test this without recompiling:If Vulkan is unavailable on a given system, GTK will silently fall back to the next available renderer — no crash risk.
Environment
gtk4crate 0.10.0)adwcrate 0.8.0)