Merge the platform and UI threads
### Update 5/20/2025 As of Flutter 3.32 stable, threads are merged by default on iOS and Android with a flag available to opt-out. In Flutter 3.33 beta changes have landed so that threads will also be merged by default on Windows and macOS. Work to merge threads on Linux is WIP. We expect that the ability to opt-out of merged threads will be removed in a later release. Known issues: * [x] https://github.com/flutter/flutter/issues/163064 * [x] https://github.com/flutter/flutter/issues/175135 * [x] https://github.com/flutter/flutter/issues/173843 ___ Currently Flutter has a separate UI thread (that runs dart code) and platform thread. I *think* the main purpose of the UI thread is to prevent blocking the platform thread, but the actual benefit of this eludes me. In most applications the platform thread stays idle apart from tiny amount of work during event processing and compositing. The work is moved to UI thread, but if the work doesn't complete in time, it causes jank just like it would when blocking the platform thread. The drawbacks however seem pretty clear. The vast majority of platform APIs need to be accessed on platform thread. This means that instead of being able to call the API from Dart directly (i.e. through FFI), platform channels or something similar need to be used to marshal the call to platform thread. This adds some friction and asynchronous behavior to what could otherwise be simple synchronous call. Situation gets even more complicated the other
Posted by knopp on Jun 19, 2024, 10:30 PM
Tags
Related issues
- [Codex Desktop][Windows] Weekly quota jumped 67 points in 38 seconds (Oct 16, 2026; 18:10 UTC)
- I loathe how difficult Matrix is for normal people though.
- Fragile against upgrades, tons of unmaintained plugins, admin panel UX is a mess where you struggle to find the stuff your are looking fo...
- Unfortunately there doesn’t seem to be any decent alternative.
- I'm wondering how much of that is bad developer UX and defaults, and how much of that is inherent complexity in the problem space.
- Pulumi support
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
ux (Sysadmin)
[Codex Desktop][Windows] Weekly quota jumped 67 points in 38 seconds (Oct 16, 2026; 18:10 UTC)
I loathe how difficult Matrix is for normal people though.
Fragile against upgrades, tons of unmaintained plugins, admin panel UX is a mess where you struggle to find the stuff your are looking fo...
Unfortunately there doesn’t seem to be any decent alternative.
I'm wondering how much of that is bad developer UX and defaults, and how much of that is inherent complexity in the problem space.
Pulumi support
[Feature]: managing cnpg in GitOps workflows (FluxCD, ArgoCD ...)
Merge the platform and UI threads
Merge the platform and UI threads
### Update 5/20/2025 As of Flutter 3.32 stable, threads are merged by default on iOS and Android with a flag available to opt-out. In Flutter 3.33 beta changes have landed so that threads will also be merged by default on Windows and macOS. Work to merge threads on Linux is WIP. We expect that the ability to opt-out of merged threads will be removed in a later release. Known issues: * [x] https://github.com/flutter/flutter/issues/163064 * [x] https://github.com/flutter/flutter/issues/175135 * [x] https://github.com/flutter/flutter/issues/173843 ___ Currently Flutter has a separate UI thread (that runs dart code) and platform thread. I *think* the main purpose of the UI thread is to prevent blocking the platform thread, but the actual benefit of this eludes me. In most applications the platform thread stays idle apart from tiny amount of work during event processing and compositing. The work is moved to UI thread, but if the work doesn't complete in time, it causes jank just like it would when blocking the platform thread. The drawbacks however seem pretty clear. The vast majority of platform APIs need to be accessed on platform thread. This means that instead of being able to call the API from Dart directly (i.e. through FFI), platform channels or something similar need to be used to marshal the call to platform thread. This adds some friction and asynchronous behavior to what could otherwise be simple synchronous call. Situation gets even more complicated the other
Comments (0)
No comments yet. Start the discussion.