perf(player): cut wasted per-frame rebuilds during playback#1019
Open
JenteJan wants to merge 1 commit into
Open
perf(player): cut wasted per-frame rebuilds during playback#1019JenteJan wants to merge 1 commit into
JenteJan wants to merge 1 commit into
Conversation
Profiling steady-state playback on macOS (libmpv path, shared with Windows) showed the Flutter layer doing needless work while watching, even though the video itself is composited cheaply by mpv. - Unmount the overlay controls once their hide animation finishes, so their position-driven Consumers stop rebuilding while the overlay is hidden (the common 'just watching' case). Remount before fading back in. Steady-state UI work drops to ~3 idle frames/sec. - Only build the progress-bar scrub-preview card while it is actually visible; it was building and laying out its image/trickplay subtree on every frame behind opacity 0 (the dominant LAYOUT cost when controls are shown). - Narrow the audio queue / queue-dialog watches to repeatMode via select() instead of watching the whole playback model, so they no longer rebuild and re-map the entire queue on every position tick. No behavioural change; pure rebuild-scope reduction.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request Description
Three rebuild-scope cleanups in the video player. No behaviour change — purely doing less redundant work during playback.
opacity: 0when auto-hidden, so their position-drivenConsumers kept rebuilding (~1–2×/sec from position ticks) the whole time you're just watching. Now dropped from the tree once the hide animation finishes, and remounted before fading back in.chapterCardbuilt and laid out its image /TrickPlayImagesubtree on every frame behindopacity: 0. For trickplay-enabled content this means laying out a preview tile every frame even when it isn't shown. Now gated on actual hover/drag.mediaPlaybackModeland re-.map()-ed the entire queue on every position tick; they only needrepeatMode, so they nowselect()just that.Issue Being Fixed
General playback efficiency — no specific issue.
Screenshots / Recordings
N/A — no visual change.
Tested On
Checklist
Verification / honesty notes:
media_kit/libmpv desktop path, shared with Windows). The render pipeline is jank-free in every scenario (raster p99 < ~1ms), so this is not a dropped-frame fix — it removes wasted CPU/GC/main-thread work, with benefit scaling on trickplay-heavy content and weaker hardware. No fabricated fps numbers.