SUPER+L layout cycle stalls Hyprland ~150 ms when switching to floating: 3-4 full config reloads per keypress

System details

• Omarchy 4.5.0rc1-1 (omarchy 4.5.0rc1-1), Hyprland 0.56.2-4, kernel 7.2.8-9-omarchy
• AMD Ryzen 9 5900X, amdgpu, single LG HDR 4K (DP-3, 3840x2160@60, scale 2)
• Default bindings: SUPER + L = omarchy-hyprland-workspace-layout-toggle

What's wrong?

Cycling a workspace through its layouts with SUPER + L is not smooth, and switching to floating freezes the desktop for ~150 ms. Going to floating does not look like a layout change at all: the screen sits on the old picture, jumps once to floating windows without titlebars, sits again, then the titlebars and dock appear.

Steps to reproduce (four tiled foot windows on one workspace):

1. SUPER + L — dwindle -> scrolling. No freeze, but the geometry changes in a single frame (no transition), and on a 1920-wide viewport the windows land at x = -2273, -1102, 65, 1231: two of the four are now entirely off-screen and the focused one is cut off at the right edge.
2. SUPER + L — scrolling -> floating. Visible freeze, then floating windows without titlebars, another pause, then titlebars and the dock.
3. SUPER + L — floating -> dwindle. A shorter freeze.

Measured with 60 fps screencopy, a hyprctl -j version round-trip probe (which blocks on the compositor's main thread), and .socket2.sock events:

Idle baseline for that probe: median 4 ms, p99 5 ms. The four configreloaded events of one floating press land at +128, +129, +180 and +202 ms after the keypress.

The reload count does not depend on the workspace being visible: with the same four windows on a hidden workspace, the real script produced 4 reloads per press, while

hyprctl eval 'o.workspace_mode({ workspace = "9", mode = "floating" })'

on its own took 5-6 ms with 0 reloads. So the mode application is cheap; the reloads come from the toggle script / titlebar path. Single dispatches (tag, float, resize, center, move) are 4-5 ms each with 0 reloads, and hyprctl reload alone is 27 ms.

Relevant code:

• omarchy-hyprland-workspace-layout-toggle runs hyprctl reload at the end when hyprbars is missing from hyprctl plugin list -j.
• default/hypr/workspace-modes.lua:454 titlebars() calls hl.plugin.load(TITLEBARS) and the comment above it says the plugin reloads the config once it is in.
• workspace-modes.lua:508 M.apply() re-runs arrange(hl.get_windows()) on every config load, and set_up_floating() (line 531) can load the plugin again after each reload.
• arrange() issues six synchronous dispatches per window (two tags, float, resize, center, move) inside a single hyprctl eval.

For the dwindle <-> scrolling half, hyprctl animations -j reports windowsMove as enabled: true, speed: 0.00, bezier: "", so there is no move animation configured and the re-tile is an instant jump, which is the "not smooth" part even without a freeze.

Expected: one keypress should not reload the compositor's config 3-4 times, and should not hold the main thread for ~150 ms; the two tiled layouts should at least not leave windows outside the viewport after the switch.

I have the 60 fps recording, per-frame extracts, the event/latency logs and the capture scripts kept aside; I can attach them or open a draft PR if that helps.