[Windows] Add force redraw to the C++ client wrapper

[loic-sharma]

This change adds a C++ client wrapper to Windows's "force redraw" C API. This API can be used to schedule a frame.

Part of flutter/flutter#119415

Background

The Windows runner has a race at startup:

1. Platform thread: creates a hidden window
2. Platform thread: launches the Flutter engine
3. UI/Raster threads: renders the first frame
4. Platform thread: Registers a callback to show the window once the next frame has been rendered.

Steps 3 and 4 happen in parallel and it is possible for step 3 to complete before step 4 starts. In this scenario, the next frame callback is never called and the window is never shown.

The Windows runner will be updated to call the "force redraw" API after it registers the next frame callback. If step 3 hasn't completed yet, the "force redraw" will no-op as a frame is already scheduled. If step 3 has already completed, the "force redraw" will schedule another frame, which will call the next frame callback and show the window.

See this discussion below on why we cannot avoid changing the Windows runner to fix this issue: #42061 (comment)

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[cbracken]

The change itself seems technically correct and tested, but I wonder if there's a way to do this without adding public API -- i.e. trigger this from the internal window.cc when it goes from hidden to shown?

I don't think there's necessarily anything wrong with adding public API to support this -- we expose frame scheduling to the Dart side app too -- but it would be nice to just do the right thing automatically with no new code in the runner, if we can.

[loic-sharma]

but it would be nice to just do the right thing automatically with no new code in the runner, if we can.

I don't think we can avoid changing the runner. The "correct" solution would be to add the view and register the next frame callback atomically. This would require non-trivial embedder API changes. Currently both of these operations work by enqueueing work to the raster thread's task runner - nothing prevents these two tasks from being interleaved with raster operations submitted by the UI thread. In other words, we cannot avoid this race simply by moving/reordering when we add the view or the next frame callback.

Another potential solution would be to register the "show window" callback after we've created the view but before we've sent the window metrics:

engine/shell/platform/windows/flutter_windows.cc

Lines 78 to 87 in 5cf141f

	if (!state->view->GetEngine()->running()) {
	if (!state->view->GetEngine()->Run()) {
	return nullptr;
	}
	}
	// Must happen after engine is running.
	state->view->SendInitialBounds();
	state->view->SendInitialAccessibilityFeatures();
	return state.release();

This would require changes to the Windows embedder's runner API: the FlutterViewController's constructor would need to accept a "show window" callback that is passed to the Windows embedder's FlutterDesktopViewControllerCreate (or some fork to avoid breaking changes). The runner would still need to be modified to something like:

bool FlutterWindow::OnCreate() {
  // ...
  flutter_controller_ = std::make_unique<flutter::FlutterViewController>(
-     frame.right - frame.left, frame.bottom - frame.top, project_);
+     frame.right - frame.left,
+     frame.bottom - frame.top,
+     project_,
+     [&]() {
+       this->Show();
+     });
  // Ensure that basic setup of the controller was successful.
  if (!flutter_controller_->engine() || !flutter_controller_->view()) {
    return false;
  }
  RegisterPlugins(flutter_controller_->engine());
  SetChildContent(flutter_controller_->view()->GetNativeWindow());

- flutter_controller_->engine()->SetNextFrameCallback([&]() {
-   this->Show();
- });

  return true;
}

The "force frame" approach requires the following runner modification:

```diff
bool FlutterWindow::OnCreate() {
  // ...
  flutter_controller_ = std::make_unique<flutter::FlutterViewController>(
     frame.right - frame.left, frame.bottom - frame.top, project_);
  // Ensure that basic setup of the controller was successful.
  if (!flutter_controller_->engine() || !flutter_controller_->view()) {
    return false;
  }
  RegisterPlugins(flutter_controller_->engine());
  SetChildContent(flutter_controller_->view()->GetNativeWindow());

  flutter_controller_->engine()->SetNextFrameCallback([&]() {
    this->Show();
  });

+ // It is possible Flutter rendered the first frame before the "show window"
+ // callback was registered. In case this happened, schedule another frame to
+ // ensure the window is shown. This no-ops if the first frame hasn't completed yet.
+ flutter_controller_->ForceFrame();

  return true;
}

In my mind the "force frame" approach is the least intrusive change to the Windows runner.

[cbracken]

Thanks for the detailed write-up; agreed the required embedder API changes to work around this aren't worth it, plus we already expose this to the Dart bits of the app and it's in the C API anyway.

lgtm

[yaakovschectman]

LGTM if we want this in the API