-
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 |
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 :) |
@@ -867,7 +867,14 @@ static bool ClipRRectContainsPlatformViewBoundingRect(const SkRRect& clip_rrect, | |||
|
|||
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 [email protected] Revert "Replace deprecated and internal Skia EncodedImage calls with public versions" (flutter/engine#41595) 2023-04-28 [email protected] Roll buildroot to c96c9d4641714301fab450a5f3b0f3c42712e1e3 (flutter/engine#41589) 2023-04-28 [email protected] [platform_view] Only dispose view when it is removed from the composition order (flutter/engine#41521) 2023-04-28 [email protected] Determine lifecycle by looking at window focus also (flutter/engine#41094) 2023-04-28 [email protected] Increase timeout for clang-tidy on mac (flutter/engine#41588) 2023-04-28 [email protected] [Impeller] Always enable validation for goldens (flutter/engine#41574) 2023-04-28 [email protected] fuchsia: do not read version_history.json (flutter/engine#41585) 2023-04-28 [email protected] Roll Dart SDK from c7160d4ea0b7 to 8e9bf2bb9878 (5 revisions) (flutter/engine#41586) 2023-04-28 [email protected] Replace deprecated and internal Skia EncodedImage calls with public versions (flutter/engine#41368) 2023-04-28 [email protected] 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 [email protected],[email protected],[email protected] 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.