Restores Archie, the server monitor and the full-width bar surface. None of
today's changes fixed the stutter, and the surface refactor regressed it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reverting the diagnostic. The narrow surface is still the right destination
but it needs the frame band drawn without adding a second full-screen
surface, which is what the reverted attempt got wrong.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The bar's PanelWindow was screen-sized because the frame band and every
panel drew into it. Hyprland blurs that namespace, and blur is recomputed
whenever what is behind the surface changes — with a game underneath, that
is every pixel every frame. Measured at 3440x1440 it cost a third of the
card; the diagnostic shrink took game-running GPU 57% -> 38% and made the
stutter unprovokable.
So the surface is now barWidth at rest and grows to the screen only while a
dropdown, the toast or the launcher is up. exclusiveZone is unchanged, so
windows never reflow on resize. chromeSdf's cutout derives from
screen.width rather than the surface width, so the shader is identical at
both sizes and the narrow surface simply clips it.
The frame band moves to its own background-layer surface, below windows and
matched by no blur rule. Its shader hides (rather than the window
unmapping, which would flicker) while the bar is wide, since chromeSdf then
draws the frame itself and melts panels into it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Archie goes for good — he'd have had to move to the background layer with
the frame band, and that isn't where he belongs. History has him.
The implicitWidth change is a diagnostic, not a design: it clips the frame,
panels, toast and launcher, which all draw into this one screen-sized
surface. Every cost measured today (blur 84->62, SDF 27->17) scales with
that area, so this tests whether shrinking it is worth a real refactor
before committing hours to one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The SSH qs-stats stream and the router ping both tick every 2s, and each
tick rewrote six Text items in the bar. That surface is the whole screen,
so every tick repainted 3440x1440, reran the SDF shader and made Hyprland
recompute the blur behind it — one late frame, twice a second. Suppressing
both processes was the only change all day that held the frametime graph
flat under deliberate provocation.
Archie was measured innocent and comes back. The OSD anchored its y to the
glance widget, so it now derives from barBottom instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
As a user sheet it sorted below userChrome.css and lost every !important to
the copy parsed at startup. Agent sheets sort above ua.css; @-moz-document
keeps that origin off web pages.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The watcher not landing left Zen with no theme at all. Keep the startup copy
so the floor is the old behaviour, and let the watcher fight for the live
update on top.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gecko has no userChrome.css reload, so wrap zen with a mozilla.cfg script
that registers chrome/zen-theme.css through nsIStyleSheetService and
re-registers it under a cache-busting URI when its mtime moves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
theme-apply sent reload-config to com.mitchellh.ghostty only, and its
comment claimed the scratchpad 'is the same process'. It is not — that
is the whole point of the --class in settings/hyprland.nix. Ghostty's
--class IS the GTK application id, which is how it forces a separate
instance, and a separate instance owns its own bus name and object path.
So the scratchpad never got the reload and kept the old palette until it
was killed.
Now both are told, scratchpad first and best-effort, since it only
exists once SUPER+Return has been pressed this session.
