commit c958e8313c782ea1df62b384a5dc85a2db5f747b
author auto-submit[bot] <98614782+auto-submit[bot]@users.noreply.github.com> Fri Jun 06 17:58:16 2025 +0000
committer GitHub <noreply@github.com> Fri Jun 06 17:58:16 2025 +0000
tree 7b3a090dcabbec4c710cc15423d7fe1f56e18ef1
parent 894fbf6d5323bf0e6fcd3b1170eef932f646cec5

Reverts "Lazy paths and frame object arenas (#168996)" (#170164)

<!-- 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>