Black screen flash (~100ms) when transitioning between assets

[Glassto]

Description

When Anthias switches from one asset to the next (image/video/webpage) in the playlist, the screen briefly flashes black for roughly 100-200ms before the next asset appears. It's quite jarring visually and noticeably disrupts the viewing experience, especially when the playlist has short-duration assets and transitions happen frequently.

Steps to Reproduce

1. Set up a playlist with 2 or more assets (e.g., image → image, image → video)
2. Let the playlist run in the viewer
3. Observe the screen during the transition between assets
4. Screen flashes black for ~100-200ms before the next asset appears

Expected Behavior

Assets should transition smoothly (e.g., instant cut or fade) without a visible black screen flash in between.

Screenshots

N/A (brief timing-based visual glitch, hard to capture in a still screenshot

Environment

• Device: Raspberry Pi 4
• OS: balenaOS
• Anthias Version: v2026.8.0
• Installation Method: Release Image

[vpetersson]

This depends on a lot of things, and it isn't as straight forward as 'adding transitions' on a Raspberry Pi. If you did the same thing with Anthias on a PC, I doubt you would see any transitions. It also depends a lot on the asset type. Images to images it should be more or less non-existing on a Pi 4/5 with a fast SD card. Images to web/video you might see it however, as it is due to the load time.

It's solved in Screenly, but it requires a significant amount of engineering effort to solve.

[Glassto]

Thanks for the context,that matches what I'd expect given the load-time dependency for web /video assets.

Since anthias-viewer is Qt/QML-based (confirmed by the recent switch to QML VideoOutput in a QQuickWidget), I think the black flash is really two separate problems that could be solved independently, and neither necessarily requires "adding transitions" as an feature:

1. Image -> image (Pi 4/5, fast SD card)
If this is "more or less non-existing" as mentioned, the remaining flash is likely just the QML scene graph swapping the active Image element's source synchronously. The old frame is torn down before the new one is composited. A simple opacity crossfade between two stacked Image elements (ping-pong between them on each asset change) would smooth this out with near-zero engineering cost, since it's pure QML/declarative and doesn't touch asset loading at all.

2. Image/video -> web, or ->video
This is the load-time case you mentioned. The fix here isn't a visual transition, it's decoupling load from switch:

• Keep the current asset rendering on screen.
• Instantiate the next asset (WebEngineView /VideoOutput/Image) off-screen or at opacity: 0, and start loading/buffering it in the background while the current asset's duration counts down.
• Only swap visible/opacity once the incoming asset reports ready (Image.status === Image.Ready, MediaPlayer.status === MediaPlayer.Buffered, or WebEngineView.loadingChanged -> LoadSucceededStatus).
• If the next asset isn't ready by the time the current one's duration expires, either hold the current frame a bit longer or fall back to today's behavior (brief black). Will degrade gracefully instead of blocking playback indefinitely.

This is essentially double-buffering the viewer instead of single-buffering it, which is what most signage players (including, it sounds like, Screenly's managed product) do to avoid this exact issue.

Suggested scope to keep low the engineering effort:

• Start with case number1 only (image->image crossfade) as a low-risk, self-contained PR, it's a pure QML change in the viewer's transition logic, no changes to asset scheduling/Celery/download pipeline needed.
• Gate it behind a Settings toggle (e.g., TRANSITION_STYLE: none | fade) so it's opt-in and doesn't change default behavior or risk performance regressions on low-end boards (Pi 2/3).
• Treat number2 (preload/prefetch for web&video) as a follow-up, since it touches asset loading timing and would need more testing across board types.