mirror of
https://github.com/flutter/flutter.git
synced 2026-02-20 02:29:02 +08:00
c958e8313c
<!-- start_original_pr_link --> Reverts: flutter/flutter#168996 <!-- end_original_pr_link --> <!-- start_initiating_author --> Initiated by: zanderso <!-- end_initiating_author --> <!-- start_revert_reason --> Reason for reverting: Failing in post submit on web_long_running_tests_3_5 <!-- end_revert_reason --> <!-- start_original_pr_author --> Original PR Author: eyebrowsoffire <!-- end_original_pr_author --> <!-- start_reviewers --> Reviewed By: {mdebbar} <!-- end_reviewers --> <!-- start_revert_body --> This change reverts the following previous change: The lifecycle of `Path` objects are currently not managed by the user. That is to say, there is no `dispose` method on path objects and therefore no explicit way to detect when the user is done with the path object and the native-side object can be exposed. As of right now, we use `FinalizationRegistry` to clean up the native-side objects when the dart-side objects are garbage collected. However, this has a number of issues: * Adding objects to the finalization registry actually ends up prolonging their lifetime in V8, since the V8 garbage collector will only collect them in a major GC and not a minor GC once they are registered with the finalization registry. See the following Chrome bug: https://issues.chromium.org/issues/340777103 * We can run into OOM issues where the linear memory of canvaskit/skwasm exceeds 2GB if the collection of paths go on too long. * Even if the paths do get collected by the GC, they often happen infrequently enough that paths over many frames have accumulated and are being collected all at once. This gap can often be dozens or hundreds of frames long, and when collection does occur it is freeing a lot of paths at once, which causes a janky frame. I have seen this take upwards of 800ms on my M1 Macbook Pro. There are some more details in https://github.com/flutter/flutter/issues/153678 This PR alleviates this issue by creating a `LazyPath` object. This object is added to an arena that explicitly collects the underlying native objects at the end of each frame. The object also tracks the API calls made to it so that if it is actually used across a frame boundary that we can recreate the native object if it was freed. Running our benchmarks, this has a non-trivial performance cost to building and using these paths (30-50% in a microbenchmark, 3-6% in a broader full app benchmark). However, as a team we've decided that this cost is worth it to avoid OOM issues as well as the non-deterministic jank associated with large collections of these objects. <!-- end_revert_body --> Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
Flutter Engine
Setting up the Engine development environment
See here
gclient bootstrap
Flutter engine uses gclient to manage dependencies.
If you've already cloned the flutter repository: