mutmut
August 27, 2026, 6:02pm
1
Well, it’s done, the switch happened all by itself!
First observation, the scroll is a bit long/heavy/not snappy, I’m not sure how to describe it, but it feels like there’s a lot to move (Firefox 154/macOS 14.8.9/OCLP for MBPR2013).
I have a similar feeling on Android 16 Chrome or on the iPad Pro IOS17 Safari.
It lags a bit, lacks responsiveness when scrolling, as if the FPS were a bit too low…
guim31
August 27, 2026, 6:21pm
3
I’m seeing the same thing
Hi everyone!
This topic is now in development .
A PR has been opened to paint the Horizon scene on a fixed layer and remove the dashboard scroll lag:
master ← claude/gladys-horizon-scroll-lag-0iahh4
ouvert 06:31PM - 27 Aug 26 UTC
### Description
Fixes the scroll lag reported on the v5 Horizon dashboard (Fire… fox 154, MacBook Pro 2013).
The dashboard painted its Horizon scene with `background-attachment: fixed` on the scrolling element itself, which forces a **main-thread repaint of the whole gradient on every scroll frame**. Under cards that re-blur their `backdrop-filter` backdrop each frame, that repaint is what made scrolling feel heavy on modest hardware. The Activity page had already moved to a dedicated `position: fixed` scene layer for exactly this reason (see the comment in `routes/history/style.css`).
This PR applies the same mechanism to `.dashboardBackground`, which is shared by the dashboard, its editor, the settings, devices, scenes, calendar, auth and integration pages — they all get the same scroll-performance win:
- The scene classes keep setting `background-image` on the page element, but the element now paints it at zero size (`background-size: 0 0`). A fixed, full-viewport `::before` inherits the image and is **composited once, never repainted while the page scrolls**.
- The fixed layer covers the viewport, so it also slides under the nav rail and the mobile top bar (their backdrop blur keeps frosting the actual scene) without the old width/margin trick, which is removed. The mobile margin trick stays: it keeps `min-height: 100vh` ending exactly at the viewport bottom.
- The layer needs its own stacking context (`isolation: isolate`) to sit behind the content but above the dark-mode opaque `.page-main` background — and a stacking context on the page would trap any full-screen overlay rendered inline inside it below the nav rail (`z-index: 1040`). The two remaining inline modals (device migration, external integration store) are therefore portaled to `<body>`, like the light control panel, the CSV export sheet and the date picker already are. That also frees them from the `backdrop-filter` containing block of the glass card they open from.
Verified on the demo build (Chromium): dashboard light/dark, scrolled, mobile, settings and integrations pages all render identically, with the scene staying viewport-fixed during scroll.
Possible follow-up if reports persist on old hardware: the `blur(28px)` backdrop of every card is the remaining per-frame GPU cost while scrolling; a `prefers-reduced-transparency` fallback could offer opaque cards.
## Forum
Forum: https://community.gladysassistant.com/t/lag-pendant-le-scroll/10719
### Checklist
- [x] Tests pass: no server change (front-only CSS/markup change); Cypress could not run in this environment (binary unavailable), verified with a full front build + Playwright screenshots instead
- [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier-check`)
- [x] No undocumented breaking change
---
_Generated by [Claude Code](https://claude.ai/code/session_01Qwnq74KtEvp3Qcri5EQuUa)_
Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed.
Can someone with Gladys Plus confirm that it’s better on this URL? https://claude-gladys-horizon-scroll.gladys-plus.pages.dev/
guim31
August 27, 2026, 6:46pm
7
I confirm that this is perfectly smooth!
mutmut
August 27, 2026, 6:46pm
8
Tested but not validated
guim31
August 27, 2026, 6:55pm
9
So I specify that at my place it’s smooth AND quite fast and « light ».
My phone:
Thanks @guim31 @GBoulvin , at least we fixed a first bug
@mutmut Claude says: On a 2013 MacBook Pro running OCLP, it’s very likely that Firefox is running in software WebRender (OCLP patches often degrade GPU acceleration) — and in software rendering, this volume of blur will never be smooth, no matter what we optimize around. It would be worth asking mutmut what about:support displays → the « Composition » line: if it’s « WebRender (Software) », we have our complete explanation.
Have you tested on another browser (Safari, Chrome?)
mutmut
August 27, 2026, 7:03pm
12
Well, yes, I had a bit of an idea with OCLP.
Well, there’s our answer ^^
Can you use another browser?
If this is a recurring request, we could create a « degraded » mode, but given that it runs very well even on an iPhone 12, this is really a software issue related to your Firefox.
mutmut
August 27, 2026, 7:34pm
14
ok so the problem is Firefox
On my end, I don’t notice any lag, neither on Firefox/Chrome Windows 11, nor on Chrome on Android 16.
