Et bien c’est fait, la bascule s’est faite toute seule !
Première remarque, le scroll est un poil long/lourd/pas vif, je ne sais pas trop comment le qualifier mais on a l’impression qu’il y a beaucoup de monde à bouger (firefox 154/macos 14.8.9/OCLP pour MBPR2013)
J’ai un peu le même ressenti sous Android 16 Chrome ou sur l’iPad Pro IOS17 Safari.
Ça lag un peu, manque de réactivité au scroll, comme si les FPS étaient un peu trop faibles…
Je constate la même chose
Fable 5 est sur le coup !
Salut tout le monde !
Ce sujet est désormais en cours de développement .
Une PR a été ouverte pour peindre la scène Horizon sur un calque fixe et supprimer le lag au scroll du dashboard :
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)_
N’hésitez pas à suivre la PR, à tester (optionnel, surtout pour les petites demandes) et à faire vos retours ici si besoin.
Quelqu’un qui a Gladys Plus peut me confirmer que c’est mieux sur cette URL ? https://claude-gladys-horizon-scroll.gladys-plus.pages.dev/ ?
Je confirme que là c’est parfaitement smooth !
Testé mais pas validé
Alors je précise que chez moi c’est smooth ET tout à fait rapide et « leger ».
Mon téléphone :
Merci @guim31 @GBoulvin , au moins on a corrigé un premier bug
@mutmut Claude me dit : Sur un MacBook Pro 2013 sous OCLP, il est très probable que Firefox tourne en WebRender logiciel (les patchs OCLP dégradent souvent l’accélération GPU) — et en rendu logiciel, ce volume de blur ne sera jamais fluide, quoi qu’on optimise autour. Ça vaudrait le coup de demander à mutmut ce qu’affiche about:support → ligne « Composition » : si c’est « WebRender (Software) », on a notre explication complète.
Tu as testé sur un autre navigateur (Safari, Chrome?)
alors oui, je me doutais un peu avec OCLP.
Bon, on a notre réponse ^^
Tu as la possibilité d’utiliser un autre navigateur ?
Si c’est une demande récurrente, on pourra faire un mode « dégradé », mais bon vu que ça tourne très bien même sur un iPhone 12, là c’est vraiment un souci logiciel lié à ton Firefox.
ok donc le problème est firefox
De mon côté je ne constate pas de lag ni sur Firefox/Chrome Windows 11, ni sur chrome sur android 16
