Skip to content

fix(windows): defer player startup initialization - #1081

Open
vicente-higino wants to merge 2 commits into
DonutWare:developfrom
vicente-higino:codex/windows-deferred-player-startup
Open

fix(windows): defer player startup initialization#1081
vicente-higino wants to merge 2 commits into
DonutWare:developfrom
vicente-higino:codex/windows-deferred-player-startup

Conversation

@vicente-higino

Copy link
Copy Markdown

Summary

Separates the remaining Windows startup-initialization fix from the window-management changes discussed in #1069.

On Windows, the video backend and system media controls are no longer initialized during application startup. They initialize on the first playback request instead. Concurrent initialization requests share one operation, while failed attempts remain retryable.

Other platforms retain their existing eager player initialization behavior.

Relates to #1001 and follows the investigation in #1069.

Root cause and scope

After the delayed window-restoration and Flutter-child fixes were applied, an intermittent unresponsive launch still occurred. The remaining startup path eagerly initialized the native player and awaited SMTC before window setup. Deferring that work removed the remaining freeze from repeated A/B launch testing.

Changes

  • Remove SMTC initialization from the desktop startup critical path.
  • Lazily initialize the video player on Windows.
  • Keep eager initialization unchanged on non-Windows platforms.
  • Coalesce concurrent player initialization requests.
  • Initialize SMTC on demand when media keys are enabled.
  • Allow failed player and SMTC initialization to be retried.
  • Await player setup and subscription cleanup.
  • Add focused single-flight and player-initialization tests.

Validation

  • Dart formatting at the repository's 120-column width: clean.
  • flutter test --no-pub test\single_flight_initializer_test.dart test\video_player_initialization_test.dart: 5/5 pass.
  • flutter analyze --no-pub: no issues.
  • Independent Windows release build succeeds with Flutter 3.35.7.
  • A/B result: the window-only build still produced an intermittent unresponsive launch; after adding this change, 30/30 normal launches were responsive and visible.
  • Across the final 50-launch normal/maximize stress matrix, there were zero freezes and zero invisible Flutter views.
  • Contributor manually confirmed the combined build behaves correctly.

AI Assistance Disclosure

This change was developed with assistance from OpenAI Codex. Codex was used to isolate the remaining startup work after the window fix, implement retryable single-flight initialization, add regression tests, rebase across the latest upstream player changes, build the release, and run repeated startup probes.

Approximately two additional hours of active AI-assisted A/B investigation, implementation, rebasing, and validation went into this portion, in addition to the contributor's manual testing. The extra time was necessary because the native player/SMTC workload was intermittent and initially looked like the window-placement freeze; repeated isolated builds were required to distinguish the two causes.

@vicente-higino
vicente-higino marked this pull request as ready for review August 10, 2026 00:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant