mutmut
27. August 2026 um 18:02
1
Und schon ist es geschafft, der Wechsel hat sich ganz von alleine vollzogen!
Erste Anmerkung: Das Scrollen ist ein bisschen lang/schwer/unflüssig, ich weiß nicht genau, wie ich es beschreiben soll, aber man hat das Gefühl, dass es sehr viel zu bewegen gibt (Firefox 154/macOS 14.8.9/OCLP für MBPR2013).
Ich habe ein ähnliches Gefühl unter Android 16 Chrome oder auf dem iPad Pro IOS17 Safari.
Es hat etwas gelaggt, mangelnde Reaktivität beim Scrollen, als ob die FPS etwas zu niedrig wären…
Hallo zusammen!
Dieses Thema ist nun in Entwicklung .
Ein Pull Request wurde eröffnet, um die Horizon-Szene auf eine feste Ebene zu malen und das Scroll-Lag im Dashboard zu entfernen:
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)_
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed modal overlays appearing behind or being constrained by glass-style containers.
* Improved modal layering and positioning across device migration and external integration workflows.
* Reduced scrolling flicker and improved background scene rendering performance on dashboard and history views.
Zögert nicht, dem PR zu folgen, es zu testen (optional, besonders bei kleinen Anfragen) und euer Feedback hier zu hinterlassen, falls nötig.
Kann mir jemand, der Gladys Plus hat, bestätigen, dass es auf dieser URL besser ist? https://claude-gladys-horizon-scroll.gladys-plus.pages.dev/
guim31
27. August 2026 um 18:46
7
Ich bestätige, dass es hier perfekt reibungslos läuft!
mutmut
27. August 2026 um 18:46
8
Getestet, aber nicht validiert
guim31
27. August 2026 um 18:55
9
Ich präzisiere, dass es bei mir „smooth“ und absolut schnell und „leicht“ ist.
Mein Telefon:
Danke @guim31 @GBoulvin , zumindest haben wir den ersten Bug behoben
@mutmut Claude sagt: Auf einem MacBook Pro 2013 unter OCLP ist es sehr wahrscheinlich, dass Firefox im Software-WebRender läuft (die OCLP-Patches verschlechtern oft die GPU-Beschleunigung) — und bei Software-Rendering wird dieses Blur-Volumen niemals flüssig sein, egal was man optimiert. Es wäre einen Versuch wert, mutmut zu fragen, was about:support anzeigt → Zeile „Komposition“: Wenn dort „WebRender (Software)“ steht, haben wir die vollständige Erklärung.
Hast du es mit einem anderen Browser (Safari, Chrome?) getestet?
mutmut
27. August 2026 um 19:03
12
ja, ich hatte es schon ein bisschen mit OCLP vermutet.
Gut, wir haben unsere Antwort ^^
Kannst du einen anderen Browser verwenden?
Falls es eine häufige Anfrage ist, können wir einen „abgespeckten“ Modus machen, aber da es selbst auf einem iPhone 12 sehr gut läuft, ist das wirklich ein Softwareproblem mit deinem Firefox.
mutmut
27. August 2026 um 19:34
14
ok also liegt das Problem bei Firefox
Chris75
27. August 2026 um 19:37
15
Von meiner Seite aus stelle ich weder Lags auf Firefox/Chrome Windows 11 noch auf Chrome auf Android 16 fest
