Actually let me investigate if I can only halt one view's rendering instead of all views'.

I think sharing the thread synchronizer is the way to go, but it should probably be aware of multiview.

So the API should look maybe something like:

@interface FlutterThreadSynchronizer : NSObject

- (void)view:(ViewId)viewId beginResize:(CGSize)size notify:(nonnull dispatch_block_t)notify;
- (void)view:(ViewId)viewId performCommit:(CGSize)size notify:(nonnull dispatch_block_t)notify;
- (void)viewShutDown:(ViewId)viewId

The waiting for content size would become a Map<ViewId, CGSize>.

beginResize would block until all pending frames for ViewId->Size are satisfied.
performCommit would update the size for given viewId.

The _shuttingDown however would probably also needed to be tracked per view.

@knopp Yeah, that's what I did in this PR. The method name is a little different, but I can switch to yours.

I don't think shutdown should be tracked per view, because [FlutterView shutdown] is only set when the engine is disposed. We can actually remove [FlutterView shutdown].

And after thinking for a while, I don't think it's possible to allow other views to rendering while one view is waiting for its correctly sized content. The rasterization for the view being resized has to fully complete before the next view can be resized, since after all the rasterization is not made async. However, this does not harm the experience at all, since the wait time should be minimal. All views continue their animation while the view is being resized.

The remaining question is, can we add a unit test? I think it'll need multi-threading (multiple task queues), but I'm not familiar with it. Can you give me some ideas?

My bad. The API seems fine, though I'm not sure what the cleanup process is.

As for the tests, there are still just two threads, right? (platform and raster). I'd just use a serial background dispatch queue for simulating raster thread (dispatch_queue_create with DISPATCH_QUEUE_SERIAL).

@knopp I've updated this PR and it should be ready for review. Changes include:

• Unit tests for the synchronizer, including its single-view capability and multiview capability.
• It no longer checks whether beginResizeForView: is called on the main thread, but whether it's called on the main queue.
  • For the real main queue, these are equivalent, since the documentation said that the main queue always executes on the main thread. However, this change allows substituting the queue with a custom one for unit tests.
• Documentation updates.
• The thread synchronizer is now assigned to FlutterViewController via the setupWithEngine:viewId:threadSynchronizer method.

Also cc @cbracken might want to take a look as well.

cc @loic-sharma since Windows might suffer from similar single-view assumption on a thread synchronizer.

auto label is removed for flutter/engine, pr: 41915, due to - The status or check suite Linux Web Framework tests has failed. Please fix the issues identified (or deflake) before re-applying this label.