-
Notifications
You must be signed in to change notification settings - Fork 6k
[platform_view] Only dispose view when it is removed from the composition order #41521
Conversation
|
@saintmac-google Do you mind to test this patch again :) thank you |
saintmac-google
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tested on our app, it works (also with std::move)
| } | ||
| views_to_dispose_.clear(); | ||
|
|
||
| views_to_dispose_ = views_to_dispose_next_frame; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be std::move(views_to_dispose_next_frame)
4daaaed to
a113c4b
Compare
|
Friendly ping @hellohuanlin :) |
| return; | ||
| } | ||
|
|
||
| FML_DCHECK([[NSThread currentThread] isMainThread]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx for the chat just now. just to check if i understand it correctly (let me know if i miss anything):
Dart layer sends separate messages (info about views_to_dispose and composition_order) to the engine. The composition_order contains what should be rendered on the current frame, and views_to_dispose contains views that needs to be disposed. We need separate messages because a platform view could be just hidden and not disposed, so it won't show up in composition_order.
The crash happens when views_to_dispose message is delivered earlier than the new composition_order (due to the async nature of the message channel). So when rendering the current frame, a platform view is already disposed, but it still exists in composition_order. The fix here is simply to delay the views_to_dispose if it's still part of composition_order, and try again next frame. Alternative fix is to remove the view from composition_order, but we decided that composition_order should be the source of truth of the current frame.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
…he composition order (flutter/engine#41521)
…he composition order (flutter/engine#41521)
…he composition order (flutter/engine#41521)
…125714) flutter/engine@98b6fab...2a84ea5 2023-04-28 zanderso@users.noreply.github.com Revert "Replace deprecated and internal Skia EncodedImage calls with public versions" (flutter/engine#41595) 2023-04-28 maruel@gmail.com Roll buildroot to c96c9d4641714301fab450a5f3b0f3c42712e1e3 (flutter/engine#41589) 2023-04-28 ychris@google.com [platform_view] Only dispose view when it is removed from the composition order (flutter/engine#41521) 2023-04-28 gspencergoog@users.noreply.github.com Determine lifecycle by looking at window focus also (flutter/engine#41094) 2023-04-28 zanderso@users.noreply.github.com Increase timeout for clang-tidy on mac (flutter/engine#41588) 2023-04-28 bdero@google.com [Impeller] Always enable validation for goldens (flutter/engine#41574) 2023-04-28 maruel@gmail.com fuchsia: do not read version_history.json (flutter/engine#41585) 2023-04-28 skia-flutter-autoroll@skia.org Roll Dart SDK from c7160d4ea0b7 to 8e9bf2bb9878 (5 revisions) (flutter/engine#41586) 2023-04-28 kjlubick@users.noreply.github.com Replace deprecated and internal Skia EncodedImage calls with public versions (flutter/engine#41368) 2023-04-28 skia-flutter-autoroll@skia.org Roll Skia from 05d09f28250a to 9867fa253064 (18 revisions) (flutter/engine#41584) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC jsimmons@google.com,rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
…tion order (flutter#41521) DisposeView happens every frame before laying out PlatformViews, with the order specified in `composition_order_`. Because `view_to_dispose_` is determined on UI thread and `composition_order_` is determined on the platform thread, there could be a race if the dart code on the UI thread runs faster than the rasterizer on the Platform thread, causing a view in `view_to_dispose_` is still in the `composition_order_`. This PR delays the views in the `composition_order_` being disposed and wait for the next frame to dispose them. fixes flutter/flutter#125223 [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
…tion order (flutter#41521) DisposeView happens every frame before laying out PlatformViews, with the order specified in `composition_order_`. Because `view_to_dispose_` is determined on UI thread and `composition_order_` is determined on the platform thread, there could be a race if the dart code on the UI thread runs faster than the rasterizer on the Platform thread, causing a view in `view_to_dispose_` is still in the `composition_order_`. This PR delays the views in the `composition_order_` being disposed and wait for the next frame to dispose them. fixes flutter/flutter#125223 [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
|
Is this only for iOS? Can you guys check below issue too? I think in android side, app crash still happening. Only iOS side after flutter stable version 3.13.x upgrade, app doesn't crash. But in android still happening.. Please help me to examine the above issue... |
DisposeView happens every frame before laying out PlatformViews, with the order specified in
composition_order_. Becauseview_to_dispose_is determined on UI thread andcomposition_order_is determined on the platform thread, there could be a race if the dart code on the UI thread runs faster than the rasterizer on the Platform thread, causing a view inview_to_dispose_is still in thecomposition_order_.This PR delays the views in the
composition_order_being disposed and wait for the next frame to dispose them.fixes flutter/flutter#125223
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.