This PR addresses performance issues in the media grid by disabling
resource-intensive CSS transitions and ensuring immediate layout
updates. Previously, the default `0.2s` transition duration for grid
reshuffling was causing browser overloads on devices with multiple live
video viewers, leading to stuttering and occasionally missing
short-lived video events.
## Changes
### 1. Disable Masonry Transitions
- Set `transitionDuration` to `0` in the Masonry configuration to
eliminate CSS-driven animations during layout.
- Set `stagger` to `0` to ensure all items move simultaneously and
instantly.
- Set `resize` to `false` in the Masonry config, as window resizing is
already efficiently handled by the controller's `ResizeObserver`.
### 2. Immediate Layout Updates
- Introduced a `_forceLayout()` method in `MediaGridController` that:
- Cancels any pending throttled layout calls to avoid redundant work.
- Triggers a browser reflow via `getBoundingClientRect()` to ensure all
element dimensions are synchronized before the next draw.
- Forces an immediate Masonry layout.
- Integrated `_forceLayout()` into `selectCell()` and `unselectAll()` to
guarantee the grid updates at the exact moment a user interacts with it.
### 3. Test Alignment
- Updated `tests/components-lib/media-grid-controller.test.ts` to
reflect the changes.
## Performance Impact
By eliminating timed transitions, we significantly reduce the peak CPU
and GPU load during grid selection changes. This results in a much
snappier UI where video viewers snap into position instantly, preventing
the "shuttering" effect and ensuring that time-critical video playback
is not interrupted by heavy animation cycles.
---------
Co-authored-by: dermotduffy <dermot.duffy@gmail.com>
This PR fixes an issue where, after running the card for a few hours,
new events (such as thumbnails and triggers) would stop showing up.
This bug was caused by the Home Assistant connection dropping and
reconnecting in the background. Event subscriptions (such as Frigate
WebSocket events established via `hass.connection.subscribeMessage`) are
bound to the connection they were created on. When the connection drops,
those subscriptions are lost, and until now, they were not being
automatically recreated when the connection was restored.
This PR ensures that when a restored connection is detected, the card
properly re-initializes the camera and view components to re-establish
these background subscriptions.
1. HA Connection Reconnect Handling (`HASSManager`)
- Added logic to detect when the Home Assistant connection transitions
from disconnected back to connected.
- When restored, the card uninitializes the `CAMERAS`, `VIEW`, and
`INITIAL_TRIGGER` initialization aspects.
- This forces the system to recreate the camera managers and
re-subscribe to the relevant WebSocket event feeds in the next render
cycle, fixing the broken thumbnail/trigger feeds.
2. Centralized Camera Teardown (`InitializationManager`)
- Improved the teardown logic by moving the
`this._api.getCameraManager().destroy()` call directly into
`InitializationManager.uninitialize` when the `CAMERAS` aspect is
targeted.
- Removed duplicate `destroy()` calls scattered across `ConfigManager`
and `CardElementManager`.
- This ensures that whenever cameras are forced to re-initialize (such
as during a reconnection event), the old manager is safely destroyed in
a centralized, predictable way without memory leaks.
3. Testing
- Added tests in `hass-manager.test.ts` to verify the uninitialization
logic fires during a reconnection event.
- Updated `initialization-manager.test.ts` to verify that
`CameraManager.destroy()` is automatically called when uninitializing
cameras.
---------
Co-authored-by: dermotduffy <dermot.duffy@gmail.com>
