mutmut
27 Agosto, 2026 18:02
1
¡Pues ya está, el cambio se ha hecho solo!
Primera observación, el desplazamiento es un poco largo/pesado/no ágil, no sé muy bien cómo calificarlo, pero da la impresión de que hay mucha gente que mover (firefox 154/macos 14.8.9/OCLP para MBPR2013)
Tengo una sensación similar en Android 16 Chrome o en el iPad Pro IOS17 Safari.
Se traba un poco, falta de reactividad al desplazarse, como si los FPS fueran un poco bajos…
¡Hola a todos!
Este tema ahora está en desarrollo .
Se ha abierto una PR para pintar la escena Horizon en una capa fija y eliminar el retraso al desplazarse por el panel de control:
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.
No duden en seguir la PR, probar (opcional, especialmente para pequeñas solicitudes) y dar sus comentarios aquí si es necesario.
¿Alguien que tenga Gladys Plus puede confirmarme que es mejor en esta URL? https://claude-gladys-horizon-scroll.gladys-plus.pages.dev/
guim31
27 Agosto, 2026 18:46
7
¡Confirmo que esto es perfectamente fluido!
mutmut
27 Agosto, 2026 18:46
8
Probé pero no validé
guim31
27 Agosto, 2026 18:55
9
Por lo tanto, aclaro que en mi caso es fluido Y bastante rápido y « ligero ».
Mi teléfono:
Gracias @guim31 @GBoulvin , al menos hemos corregido el primer error
@mutmut Claude me dice: En un MacBook Pro 2013 con OCLP, es muy probable que Firefox funcione en WebRender de software (los parches de OCLP suelen degradar la aceleración GPU) — y en el renderizado de software, este volumen de desenfoque nunca será fluido, sin importar lo que optimicemos alrededor. Vale la pena preguntarle a mutmut qué muestra about:support → línea « Composición »: si es « WebRender (Software) », tenemos nuestra explicación completa.
¿Has probado en otro navegador (Safari, Chrome?)
mutmut
27 Agosto, 2026 19:03
12
sí, sí, lo sospechaba un poco con OCLP.
Bueno, ya tenemos nuestra respuesta ^^
¿Tienes la posibilidad de usar otro navegador?
Si es una solicitud recurrente, podríamos hacer un modo « degradado », pero bueno, como funciona muy bien incluso en un iPhone 12, aquí realmente es un problema de software relacionado con tu Firefox.
mutmut
27 Agosto, 2026 19:34
14
ok entonces el problema es Firefox
Por mi parte, no detecto ningún retraso ni en Firefox/Chrome Windows 11, ni en Chrome en Android 16
