Skip to content

Turn off animations when Hyprland renders on the CPU - #17035

Merged
ryanrhughes merged 7 commits into
omacom:quattrofrom
scottjones:software-rendering-no-animations
Nov 4, 2026
Merged

ryanrhughes merged 7 commits into
omacom:quattrofrom
scottjones:software-rendering-no-animations

Conversation

@scottjones

@scottjones scottjones commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

When Hyprland has no GPU driver to draw with, Mesa falls back to llvmpipe and every animated frame is drawn on the CPU, so animations stutter and keep a core busy. This turns animations, blur and shadows off for any session whose GL renderer is llvmpipe, softpipe or "Software Rasterizer", the names Hyprland itself checks since hyprwm/Hyprland#16343 (backported in omacom/omarchy-pkgs#649). That covers Macs whose GPU isn't driven yet, VMs and broken drivers.

Hyprland doesn't tell its config or hyprctl which renderer it got, so at session start Omarchy asks Mesa on the GPU Aquamarine made primary (the first AQ_DRM_DEVICES entry that exists, then the GPU with the built-in panel, then the boot GPU), reloads with the lighter defaults and logs one journal line. Those defaults load before ~/.config/hypr, so looknfeel.lua can still turn animations or blur back on, and the Glassy toggles leave blur off.

Appearance > Animations On brings them back in such a session and remembers that for later sessions (~/.local/state/omarchy/toggles/animations-without-gpu); turning animations off clears it. The menu rows and omarchy toggle animations read the state the session is actually in, so neither claims animations are on when they aren't. A notice explains it once per machine, and not at all in a VM, whose installer already turns animations off.

Tested on an M3 Air forced onto llvmpipe for one session (Hyprland's own log said Renderer: llvmpipe): animations, blur and shadows went off, including with the Glassy bar on, turning animations and blur on in looknfeel.lua kept both on, and the notice showed. The toggle, GPU-order and once-only notice changes on top are covered by test/shell.d/hyprland-software-rendering-test.sh and test/shell.d/toggle-test.sh in CI; they haven't been run on hardware. Not tested: multi-GPU machines (including NVIDIA hybrids) and VMs.

A possible follow-up is exposing Hyprland's isSoftware() through hyprctl upstream, which would replace the Mesa probe and its guess at which GPU Hyprland picked.

🤖 Generated with Claude Code

When Mesa has no driver for the GPU behind the display, Hyprland draws every frame with llvmpipe or softpipe, and animations stutter and keep a core busy. Hyprland knows this (omacom#16343) but tells neither its config nor hyprctl, so at session start omarchy-hyprland-software-rendering asks Mesa on the DRM device Hyprland holds (omarchy-hw-software-rendering), marks the session in its runtime dir and reloads.

default/hypr/software-rendering.lua then applies Animations Off: no animations, blur or shadows. It loads after the theme and before ~/.config/hypr, so looknfeel.lua still wins, and the Glassy toggles leave blur off on the CPU. The session logs one journal line and shows one notice once the notification server is up.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@greptile-apps

greptile-apps Bot commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

[Medium impact] The PR appears safe to merge; the previous findings are fixed and no new actionable issues were found.

Summary

The PR turns off animations, blur and shadows when Hyprland renders on the CPU, while keeping personal settings and remembered choices.

  • Hyprland drops costly effects when Mesa renders frames on the CPU.
  • Appearance can keep animations on in later software-rendered sessions.

Reviews (4) · Last reviewed commit: "Ask Hyprland whether animations are on i..." · Reviewed by Greptile

Comment thread bin/omarchy-hyprland-software-rendering Resolved
The notice and journal said animations, blur and shadows were off after
checking only animations. Check all three after the reload: announce only
when all are off, and otherwise log which ones ~/.config/hypr kept on.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@omarchybot omarchybot added the enhancement New feature or request label Nov 3, 2026
ryanrhughes and others added 4 commits November 4, 2026 01:05
Aquamarine puts the GPU with the most connected built-in panels first when
AQ_DRM_DEVICES is unset, ahead of the one firmware booted on, and skips
AQ_DRM_DEVICES entries that don't exist. The detector only looked at the
first entry and boot_vga, so on a laptop whose panel hangs off the other GPU
it asked Mesa about the wrong device.

Co-Authored-By: Codex (gpt-6.1-sol) <noreply@openai.com>
The CPU-session defaults loaded no matter what the toggle said, so in a VM or
on a Mac without GPU support, Appearance > Animations On did nothing and still
said "Animations enabled". VM installs had it worse: their installer turns
animations off and promises the toggle brings them back.

Turning animations on in a CPU session now leaves a flag that lifts the
defaults for that session and later ones, and turning them off clears it. The
menu rows and the toggle read the state the session is actually in.

The notice now shows once per machine, and not at all where animations were
already off by choice, since a VM install already turned them off.
Drop the load-order trace (it never compared against the user's config, so
it passed with the order backwards), the looknfeel replay whose precedence
came from the test's own merge, the notification-server cases that test
omarchy-notification-wait, and the exact retry counts.
Comment thread bin/omarchy-hyprland-animations-off Resolved
A looknfeel.lua that turns animations back on left the CPU-session check
saying they were off, so the menu offered Animations On and the first toggle
kept them on. Without a saved choice, the check now reads animations:enabled
from Hyprland in those sessions; GPU sessions still only look at the flag.
@ryanrhughes
ryanrhughes merged commit cfd8106 into omacom:quattro Nov 4, 2026
3 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants