| commit | f4dc96aef71b430ed9e0f3f18c6777d2ceeb02da | [log] [tgz] |
|---|---|---|
| author | Tong Mu <dkwingsmt@users.noreply.github.com> | Thu May 25 15:37:35 2023 -0700 |
| committer | GitHub <noreply@github.com> | Thu May 25 22:37:35 2023 +0000 |
| tree | ff5fda4cb2c35b05de0e0342e591581a02728615 | |
| parent | f46ea7e16d8abb1ad705ebce9f8f9ca7612b7b2e [diff] |
[macOS] Multi-view thread synchronizer (#41915) This PR adapts `FlutterThreadSynchronizer` to multi-view. ### Problem The `FlutterThreadSynchronizer` is a macOS engine class to ensure that, if the current window is resized, nothing will not be presented until the layer tree is drawn with the up-to-date size. This class is not compatible with multiview. A simple way to realize it is: while the class is owned by `FlutterView`, it blocks the _global_ platform thread and rasterizer thread - there is got to be some problems. Indeed, when I was testing with multiple windows (https://github.com/flutter/engine/pull/40399), the app freezes as soon as I resize a window. The problem is because Flutter only have one rasterizer thread. When I'm resizing window A, A's synchronizer detects that the size mismatches, so it blocks the rasterizer thread to wait for an updated content with the updated size. However, window B is to be rendered next, and B's size matches and will try to rasterize, and will be blocked due to the blocked rasterizer thread, window A's updated content will never arrive, causing a deadlock. ### Changes This PR removes the single-view assumption of `FlutterThreadSynchronizer` by making it created by `FlutterEngine` and shared by all `FlutterView`s, and that it prevents rasterization for all views if any view has a mismatched size. The synchronizer is assigned to the view controller in the `attachToEngine:withId` method (now renamed to `setUpWithEngine:viewId:threadSynchronizer:`. This PR also adds unit tests for `FlutterThreadSynchronizer`, which didn't have any unit tests at all. * To achieve this, the `beginResizeForView:` method no longer checks whether is called on the main thread, but whether it's called on the main queue. These are equivalent for the real main queue, since the documentation promises that the main queue always executes on the main thread. However, this change allows substituting the queue with a custom one for unit tests. [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Flutter is Google's SDK for crafting beautiful, fast user experiences for mobile, web, and desktop from a single codebase. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source.
The Flutter Engine is a portable runtime for hosting Flutter applications. It implements Flutter's core libraries, including animation and graphics, file and network I/O, accessibility support, plugin architecture, and a Dart runtime and compile toolchain. Most developers will interact with Flutter via the Flutter Framework, which provides a modern, reactive framework, and a rich set of platform, layout and foundation widgets.
If you want to run/contribute to Flutter Web engine, more tooling can be found at felt. This is a tool written to make web engine development experience easy.
If you are new to Flutter, then you will find more general information on the Flutter project, including tutorials and samples, on our Web site at Flutter.dev. For specific information about Flutter's APIs, consider our API reference which can be found at the docs.flutter.dev.
Flutter is a fully open source project, and we welcome contributions. Information on how to get started can be found at our contributor guide.