-
Notifications
You must be signed in to change notification settings - Fork 28.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[macOS] Implement merged UI and platform thread #162883
base: master
Are you sure you want to change the base?
Conversation
6dc1b3e
to
4f80954
Compare
Awesome! Making own graphic API with FFI on macOS is impossible without this. We need to land it ASAP. |
dc3f160
to
f585e97
Compare
eb3c3b5
to
fbcd706
Compare
fbcd706
to
582cba0
Compare
Putting this as WIP. With this PR with unmerged thread, CVDisplayLink is started on UI thread and stopped on platform thread. I initially assumed that would work, but it doesn't. During resizing the CVDisplayLink sometimes creates two threads and trying to stop it deadlocks. CVDisplayLink API documentation doesn't make any threading guarantees, I assumed it was thread safe but it doesn't seem to be the case. |
I've simplified display link / vsync waiter threading model. Now everything is expected to happen on main thread. This requires one extra hop from UI to platform thread with unmerged threads, and zero extra hops when running with merged threads (which will become default). The mental overhead of trying to keep everything thread safe was probably not really worth it with unmerged threads and is definitely not worth it with merged threads. Also while not documented anywhere, |
582cba0
to
6a3e7b0
Compare
@knopp This is so great! |
6a3e7b0
to
067d3ec
Compare
067d3ec
to
ceb43c1
Compare
cc @dkwingsmt as you've also worked on the macOS embedder |
Original issue: #150525
This PR lets the macOS embedder run both with and without UI and platform thread merged.
Thread merging is controlled through
FLTEnableMergedPlatformUIThread
info.plist
option similar to iOS embedder, though the default value is currentlyfalse
.Changes in the resize / vsync synchronization:
FlutterRunLoop
class to schedule Flutter tasks on main thread in a way where it is possible to only process these (Flutter posted) tasks while waiting for correct frame size during resizing. This significantly simplifies the resize synchronization and makes the same code work both with separate UI thread and with UI and platform thread merged.FlutterThreadSynchronizer
has been renamed toFlutterResizeSynchronizer
vastly simplified, mutex and conditions are removed and the blocking is now done by only processing Flutter messages while waiting for resizing. It is now per view (instead of storing a viewId->Size map internally) and owned by the view itself, instead of engine.Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.