Breaking changes to plugin with flutter 3.29+

[srmncnk]

Flutter introduced merging of ui and platform threads with version 3.29.

This means that Dart code is executed in the same thread as the platform channel (Java/Kotlin/Swift/ObjC code).

But implicitly this is true for all instances of FlutterEngine. For this plugin, which utilizes another FlutterEngine to spawn an Isolate capable of communicating with plugins / having callbacks from plugins, this means that the core functionality is broken - spawning a new FlutterIsolate will make it run in the same thread as the main Isolate.

Possibly related to #162, not related to #160.

More details of this are being discussed here and in the upper issue. Currently the workaround is to opt-in to two flags - DisableMergedPlatformUIThread (and possibly EnablePlatformIsolates?). This will restore the previous state and FlutterEngine will continue to work as before - but these flags are bound to be deprecated at some point, at which this plugin will break and not have a workaround anymore.

[nmfisher]

@srmncnk thanks for raising this. I think best if I comment in the linked flutter issue because apart from your suggested work-around, there's nothing that can be done in this repository to address the issue.

[rlueders]

Flutter introduced merging of ui and platform threads with version 3.29.

This means that Dart code is executed in the same thread as the platform channel (Java/Kotlin/Swift/ObjC code).

But implicitly this is true for all instances of FlutterEngine. For this plugin, which utilizes another FlutterEngine to spawn an Isolate capable of communicating with plugins / having callbacks from plugins, this means that the core functionality is broken - spawning a new FlutterIsolate will make it run in the same thread as the main Isolate.

Possibly related to #162, not related to #160.

More details of this are being discussed here and in the upper issue. Currently the workaround is to opt-in to two flags - DisableMergedPlatformUIThread (and possibly EnablePlatformIsolates?). This will restore the previous state and FlutterEngine will continue to work as before - but these flags are bound to be deprecated at some point, at which this plugin will break and not have a workaround anymore.

@srmncnk I don't think what you are saying is accurate. As I indicated in my comment on a separate issue you can certainly max out all cores on a device using this Flutter Isolate package. However, as i noted in my subsequent comment, you must use an earlier commit before this package was updated to spawn isolates from the same engine group. I believe that commit is responsible for the behavior you are observing rather than the merging of the ui and platform threads.

[srmncnk]

@rlueders I think we don't disagree.

It is true that you can max out all cores if you use v2.0.4 of this plugin because engine groups were not introduced yet. That's one issue.

The second issue however comes from flutter, v3.29.x, when they introduced merged ui and platform threads, meaning that platform code (Java / Kotlin / ObjC / Swift) runs in the same thread as ui (Dart). But implicitly, that also means that every new Engine also runs in the same thread as the previous (main) engine. And since flutter_isolate utilizes a new engine to spawn an isolate, this effectively this breaks flutter_isolate.

[rlueders]

@rlueders I think we don't disagree.

It is true that you can max out all cores if you use v2.0.4 of this plugin because engine groups were not introduced yet. That's one issue.

The second issue however comes from flutter, v3.29.x, when they introduced merged ui and platform threads, meaning that platform code (Java / Kotlin / ObjC / Swift) runs in the same thread as ui (Dart). But implicitly, that also means that every new Engine also runs in the same thread as the previous (main) engine. And since flutter_isolate utilizes a new engine to spawn an isolate, this effectively this breaks flutter_isolate.

I am saying that the second issue doesn't actually exist. My testing was performed on Flutter 3.29. It would not be possible to max out multiple physical cores of a device if all flutter isolates were constrained to a single thread.

Have you tested Flutter 3.29 with engine group disabled? You should see similar/identical performance to an app running pre-Flutter 3.29.

[srmncnk]

@rlueders My testing was:
flutter 3.32 (I think 3.29 has an opt-out flag for EnablePlatformIsolates, but as the name suggests, its reversed)
flutter_isolate 2.0.4 (without engine groups)
ffi call to syscall(SYS_gettid) (getting the thread id)

With that setup, all thread ids of all isolates (main and all secondary flutter_isolate instances) had same thread ids. Performance was way worse.

As soon as I set DisableMergedPlatformUIThread to true, thread ids were different and performance was better.

This has little or nothing to do with engine groups. It has to do with threading and where your Dart code is actually running.