[ios][platform_view][performance] overlay intersection #50637

hellohuanlin · 2024-02-14T04:36:04Z

Address the performance of platform view due to an extra overlay. This overlay was added due to the following rounding problem:

For example, if we interleave flutter widget and platform view in a list, and let's say we have a flutter widget (top = 0, bottom = 100.1), and a platform view below that widget (top = 100.1, bottom = 200). They are NOT supposed to be overlapping. However, after rounding out, we will get flutter widget (top = 0, bottom = 101), and platform view (top = 100, bottom 200). This will result in 1 pixel overlap as long as there's a floating point in the coord.

(Quote myself from the discussion below).

List which issues are fixed by this PR. You must list at least one issue.

Fixes flutter/flutter#143420

If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.

Pre-launch Checklist

I read the Contributor Guide and followed the process outlined there for submitting PRs.
I read the Tree Hygiene wiki page, which explains my responsibilities.
I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
I listed at least one issue that this PR fixes in the description above.
I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
I updated/added relevant documentation (doc comments with ///).
I signed the CLA.
All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

hellohuanlin · 2024-02-21T01:22:25Z

We should benchmark it again when we have a better benchmark project and better toolings, but I am already getting some good result so far on my iPhone 13 mini:

Before the fix:
Run 1:

    "average_frame_rasterizer_time_millis": 7.543352459016395,
    "stddev_frame_rasterizer_time_millis": 2.3777649825315796,
    "90th_percentile_frame_rasterizer_time_millis": 11.35,
    "99th_percentile_frame_rasterizer_time_millis": 25.963,
    "worst_frame_rasterizer_time_millis": 32.74,
    "missed_frame_rasterizer_budget_count": 6,

Run 2:

    "average_frame_rasterizer_time_millis": 7.445008264462812,
    "stddev_frame_rasterizer_time_millis": 2.144756232497781,
    "90th_percentile_frame_rasterizer_time_millis": 11.018,
    "99th_percentile_frame_rasterizer_time_millis": 24.253,
    "worst_frame_rasterizer_time_millis": 26.484,
    "missed_frame_rasterizer_budget_count": 4,

Run 3:

    "average_frame_rasterizer_time_millis": 7.6296694214876055,
    "stddev_frame_rasterizer_time_millis": 2.3363895908749415,
    "90th_percentile_frame_rasterizer_time_millis": 11.072,
    "99th_percentile_frame_rasterizer_time_millis": 24.35,
    "worst_frame_rasterizer_time_millis": 27.078,
    "missed_frame_rasterizer_budget_count": 6,

After the fix:
Run 1:

    "average_frame_rasterizer_time_millis": 5.863311827956986,
    "stddev_frame_rasterizer_time_millis": 1.990753728754767,
    "90th_percentile_frame_rasterizer_time_millis": 9.91,
    "99th_percentile_frame_rasterizer_time_millis": 15.554,
    "worst_frame_rasterizer_time_millis": 16.889,
    "missed_frame_rasterizer_budget_count": 1,

Run 2:

    "average_frame_rasterizer_time_millis": 5.756603260869563,
    "stddev_frame_rasterizer_time_millis": 2.0359048913043467,
    "90th_percentile_frame_rasterizer_time_millis": 10.113,
    "99th_percentile_frame_rasterizer_time_millis": 15.44,
    "worst_frame_rasterizer_time_millis": 15.971,
    "missed_frame_rasterizer_budget_count": 0,

Run 3:

    "average_frame_rasterizer_time_millis": 5.811156756756758,
    "stddev_frame_rasterizer_time_millis": 2.0427237399561724,
    "90th_percentile_frame_rasterizer_time_millis": 9.815,
    "99th_percentile_frame_rasterizer_time_millis": 15.915,
    "worst_frame_rasterizer_time_millis": 16.57,
    "missed_frame_rasterizer_budget_count": 1,

Observation

About 22% time reduction on "average frames", and 40%+ time reduction on "worst frames". Also pretty significant reduction (800%, from 5.33 to 0.67 frames) on "missing frames". Though keep in mind that "missing frames" can vary dramatically based on how we write the sample project.

The dummy benchmark project I used is pretty much the same as https://github.com/lucalooz/flutter_ads_list_perf from flutter/flutter#129632, except that I don't use a real AdMob banner. I also put like 7-8 banners on screen. The numbers will be smaller if we have less platform views on screen.

jonahwilliams

This is great work so far! I need to study this code a bit to make sure I understand it, but I'd encourage you to get the benchmark you are using locally on CI.

If you want to pair on that, I'd be happy to sit down tomorrow or friday morning, but otherwise I'll be out a lot the rest of this week.

jonahwilliams · 2024-02-21T01:27:19Z

shell/platform/darwin/ios/framework/Source/FlutterPlatformViews.mm

@@ -706,6 +706,14 @@ static bool ClipRRectContainsPlatformViewBoundingRect(const SkRRect& clip_rrect,
      int64_t current_platform_view_id = composition_order_[j - 1];
      SkRect platform_view_rect = GetPlatformViewRect(current_platform_view_id);
      std::vector<SkIRect> intersection_rects = slice->region(platform_view_rect).getRects();
+      for (auto it = intersection_rects.begin(); it != intersection_rects.end(); /*no-op*/) {
+        if (it->width() <= 1 || it->height() <= 1) {


So if the intersection is less than a pixel in either direction, we ignore it? I suppose this makes sense - its why we were seeing those 1 pixel boundaries.

If the intersection values you are seeing are even smaller than 1px, you could tighten the condition further (i.e. 0.5 or 0.25 or 0.1) but that might be unecessary.

We are getting 1 pixel because of a roundOut operation. Note that this is already in physical pixels in integers and won't have 0.5 here.

Ahh, where does the round out happen?

The roundOut happens to both flutter layer and platform view layer. For flutter layer, it's https://github.com/flutter/engine/blob/main/display_list/geometry/dl_rtree.cc#L209, for platform view layer, it's https://github.com/flutter/engine/blob/main/flow/embedded_views.h#L343

For example, if we interleave flutter widget and platform view in a list, and let's say we have a flutter widget (top = 0, bottom = 100.1), and a platform view below that widget (top = 100.1, bottom = 200). They are NOT supposed to be overlapping. However, after rounding out, we will get flutter widget (top = 0, bottom = 101), and platform view (top = 100, bottom 200). This will result in 1 pixel overlap as long as there's a floating point in the coord.

This particular problem is scrolling though, which is a very general problem. We are treating platform views and flutter Ui as always overlapping, even if that overlap is a near infinitesimal

How is scrolling any different? It's just a layout. Scroll to pixel boundaries and the problem disappears...

Adding a 1 unit pad between the widget and the platform view would also prevent them from overlapping. Regardless of DPI, 1 unit in the framework layout coordinates will always be at least 1 pixel. That doesn't require any engine changes, just add a Padding around the widget or the PV.

This issue is a scrolling issue. Have you looked at the benchmark application?

To clarify, the overlap between (0-100.1) and (100.1-200) is 0, not 0.1. The reason we get 1 pixel overlay is because we computed the intersection AFTER we roundOut both sizes.

An alternative is to compute the intersection in the original floating point values (without roundOut).

hellohuanlin · 2024-02-21T01:43:54Z

This is great work so far! I need to study this code a bit to make sure I understand it, but I'd encourage you to get the benchmark you are using locally on CI.

If you want to pair on that, I'd be happy to sit down tomorrow or friday morning, but otherwise I'll be out a lot the rest of this week.

Jenn (OOO this week) probably has more ideas on the benchmark project (e.g. use UIWebView?) so let's wait for her.

For now this dummy project is just my personal playground. What I did was pretty much the same as https://github.com/lucalooz/flutter_ads_list_perf, except that I don't use real AdMob (since it's a non-flutter-org repo). Also I used 320x50 standard banner size, so I can fit 7-8 banners on screen, which should be enough (i guess?).

flar

This is not a robust solution and may fix a specific test case, but it will cause unintended problems with other situations.

flar · 2024-02-21T19:36:54Z

shell/platform/darwin/ios/framework/Source/FlutterPlatformViews.mm

@@ -706,6 +706,14 @@ static bool ClipRRectContainsPlatformViewBoundingRect(const SkRRect& clip_rrect,
      int64_t current_platform_view_id = composition_order_[j - 1];
      SkRect platform_view_rect = GetPlatformViewRect(current_platform_view_id);
      std::vector<SkIRect> intersection_rects = slice->region(platform_view_rect).getRects();
+      for (auto it = intersection_rects.begin(); it != intersection_rects.end(); /*no-op*/) {
+        if (it->width() <= 1 || it->height() <= 1) {


We should round out because we are looking for actual pixel interference, not intended geometry interference.

The object that ends at 100.1 could contribute up to .1 of its color to that pixel and so it contributes to that pixel and so it SHOULD be included in the query. This assumes AA rendering, which is the default. If there was non-AA rendering going on then .1 of a pixel would not render anything - but there is no way of knowing what kind of rendering is happening at this level. This could potentially be noted during DisplayList construction and the bounding rects adjusted at some cost. Also, the switch to Impeller will mean that all rendering is MSAA and we have no good way to predict how much of a pixel will be covered for a given sub-pixel overlap.

We shouldn't ignore single pixel overlaps because both contributors will attempt to modify the pixel. If you feel that the two Flutter objects should not be considered overlapping, then Flutter should not lay them out with overlapping pixels.

This goes back to my suggestion that Flutter implement pixel-aware layouts. Until it does then we end up with AA overlaps between allegedly non-overlapping widgets and we have this problem.

flar · 2024-02-21T19:37:42Z

I'd also be interested in hearing from @knopp on this.

knopp · 2024-02-21T21:34:59Z

I agree with @flar here. This seems like a result of not being aware of physical pixels on framework level. Personally I'm pixel snapping all my applications, even wrote a package for it, but it's one I wish I didn't have to write. @hellohuanlin, is there a sample project for this? I'd like to run it with pixel_snap to see if it fixes the issue.
EDIT: I see the project now.

The solution here likely helps in this scenario, but what if there is actual one pixel overlap? Unfortunately at the point where there overlap is tested the rect has already part of region and region works with integers only.

It doesn't help that unobstructed platform view overlays on iOS are currently ridiculously expensive. Up to 2 CAMetalLayers per platform view with surface of size of entire screen. I'm still hoping one they this can be implemented same way macOS embedder does it - single IOSurface shared between multiple overlay CALayers. That itself would likely solve the performance problem here.

hellohuanlin · 2024-02-21T21:42:30Z

This seems like a result of not being aware of physical pixels on framework level.

@knopp I think it's the opposite - we are supposed to do geometric intersection between 2 sizes (in floating points), but instead we did pixel intersection (in integers), resulting in a false positive detection of overlap.

The solution here likely helps in this scenario, but what if there is actual one pixel overlap?

If we do geometric intersection rather than pixel intersection, then this should be solved (if we care about this 1 pixel overlap)

knopp · 2024-02-21T21:44:16Z

Another thing to consider would be a DlRegion that uses floating point or fixed precision numbers. This would probably have some performance implications though. Edit: On second thought this is probably a bad idea, as this would probably get incorrect result because we care about physical pixels when deciding whether to display the overlay.

knopp · 2024-02-21T21:46:16Z

This seems like a result of not being aware of physical pixels on framework level.

@knopp I think it's the opposite - we are supposed to do geometric intersection between 2 sizes (in floating points), but instead we did pixel intersection (in integers), resulting in a false positive detection of overlap.

Well, yes, but if content was snapped to physical pixes then the roundOut would not do anything. So you would not get the overlap. Region represents the area of surface where something paints. If you have fractional position that means whole pixel is affected.

hellohuanlin · 2024-02-21T21:47:48Z

Well, yes, but if content was snapped to physical pixes then the roundOut would not do anything. So you would not get the overlap.

Not sure how "snapping" works. Does it mean you always align widgets in pixel grid? Can you explain more? Is there a proposal doc that I can refer to?

knopp · 2024-02-21T21:57:40Z

@hellohuanlin if you have RectA (0, 0, 1.1, 1.1) and RectB (1.1, 1.1, 2, 2), they don't overlap, geometric intersection will tell you that they don't overlap. But we don't have infinite resolution surfaces, so they both affect physical pixel 1,1, so they infact do overlap.

jonahwilliams · 2024-02-21T22:00:02Z

They do overlap from that perspective, unless the platform view is opaque and ontop . However the overlap is small and I think of the cost is severe enough we should make a fidelity trade off here

hellohuanlin · 2024-02-21T22:08:15Z

@hellohuanlin if you have RectA (0, 0, 1.1, 1.1) and RectB (1.1, 1.1, 2, 2), they don't overlap, geometric intersection will tell you that they don't overlap. But we don't have infinite resolution surfaces, so they both affect physical pixel 1,1, so they infact do overlap.

Ya, but this is doing pixel intersection of 2 rects, where colors from both rects contributes to the same pixel (which is not the case for platform view overlays).

My point is, for the purpose of platform view overlay logic, we should be doing geometric intersection, and not to put an overlay layer of size 1x1 on top of the platform view.

hellohuanlin · 2024-02-21T22:12:53Z

Let's bring the discussion to real time chat on discord if it's easier. @knopp I couldn't find your username there, so here's the link: https://discord.com/channels/608014603317936148/608021010377080866/1209974674696437781

knopp · 2024-02-21T22:44:50Z

They do overlap from that perspective, unless the platform view is opaque and ontop . However the overlap is small and I think of the cost is severe enough we should make a fidelity trade off here

It's not just fidelity. This one pixel overlay basically defeats the whole purpose of unobstructed platform views, as it is a (unnecessary) layer directly on top of ad.

Not sure how to fix this though. The proposed solution basically means if there is an intentional 1px hairline overlay somewhere it will not be rendered. Is that common? Is that going to be a problem? I'd not think so but I don't have anything to back this with.

If we want more fidelity, we'd need changes to DlRegion that'd preserve the fractional positions. I'm not to keen on that.

knopp · 2024-02-21T22:50:37Z

For the record, here is the flutter_ads_list_perf example snapped to physical pixels. As expected this solves the problem, the only overlay seems to be one for the debug banner. Unfortunately this requires a manual intervention and a third party package so not really a transparent solution.

hellohuanlin · 2024-02-22T00:22:33Z

The proposed solution basically means if there is an intentional 1px hairline overlay somewhere it will not be rendered. Is that common? Is that going to be a problem? I'd not think so but I don't have anything to back this with.

Put aside the performance impact for now, I think it is a tradeoff between false positive and false negative:

(1) The existing behavior has a false positive of the "hairline" overlay, when we interleave ads and flutter widgets in a list. Also note:

this "hairline" overlay is actually not rendered correctly, because it only receives colors from the edge of flutter side. It does not receive colors from the edge of platform view, and does not interpolate colors from both sides.
some Ad SDKs (not sure about admob tho) actually check whether ad banners are obstructed to prevent fraud.

(2) On the other hand, the new behavior has a false negative of the "hairline" overlay. It fails to display the "hairline" of 1 pixel when we actually want it. Again, even if we add this hairline, it is not rendered correctly most of the time, as it does not interpolate the colors from both sides.

Then if we weight in the performance impact, I am leaning towards the new behavior.

flar · 2024-02-22T07:50:51Z

The proposed solution basically means if there is an intentional 1px hairline overlay somewhere it will not be rendered. Is that common? Is that going to be a problem? I'd not think so but I don't have anything to back this with.

Put aside the performance impact for now, I think it is a tradeoff between false positive and false negative:

(1) The existing behavior has a false positive of the "hairline" overlay, when we interleave ads and flutter widgets in a list. Also note:

this "hairline" overlay is actually not rendered correctly, because it only receives colors from the edge of flutter side. It does not receive colors from the edge of platform view, and does not interpolate colors from both sides.

some Ad SDKs (not sure about admob tho) actually check whether ad banners are obstructed to prevent fraud.

(2) On the other hand, the new behavior has a false negative of the "hairline" overlay. It fails to display the "hairline" of 1 pixel when we actually want it. Again, even if we add this hairline, it is not rendered correctly most of the time, as it does not interpolate the colors from both sides.

Then if we weight in the performance impact, I am leaning towards the new behavior.

Just to be certain as I'm not sure we are talking about the same thing.

With a platform view at (100, 100) -> (200, 200) (it's 100x100 in size)...

an overlap rectangle of (100, 100) -> (200, 101) is a potentially unintended overlap and it probably doesn't matter to the flutter app if we ignore it (potentially a point for discussion, but I think it is unlikely) and the proposed solution would ignore it (shove it behind the platform view)

an overlap rectangle of (100, 150) -> (200, 151) is definitely absolutely an intended overlap, but it happens to only be 1 pixel in height which means the solution as proposed will delete this rendering. I really think that is bad behavior of the fix and likely just a mistake.

Now both situations could be called "hairlines", but the way that they intersect the platform view can make them seem intentional or accidental. The first case is what I believe this fix is trying to eliminate. The later case is something that this fix also eliminates that I don't think it intends to eliminate...?

flar · 2024-02-22T07:53:19Z

An alternate solution that I think doesn't have the unintended side effect of eliminating a 1-pixel line drawn across the middle of the platform view would be to simply use platform_view_bounds.RoundIn() to do the rectangle query. If a rendering intersects that rectangle then the overlap is more likely deliberate. Also, the simple case of adjacent widgets that fall on the same edge pixel as the platform view will not trigger this new query rectangle.

platform_view_bounds.RoundOut() should still be the rectangle donated to the platform to draw its widget, though.

hellohuanlin · 2024-02-22T18:29:49Z

Now both situations could be called "hairlines", but the way that they intersect the platform view can make them seem intentional or accidental. The first case is what I believe this fix is trying to eliminate. The later case is something that this fix also eliminates that I don't think it intends to eliminate...?

Good call about the second case! I was only referring to the first case (edge hairline) and was trying to explain why it's better not to show the edge hairline. But yes non-edge hairline should be shown for sure.

An alternate solution that I think doesn't have the unintended side effect of eliminating a 1-pixel line drawn across the middle of the platform view would be to simply use platform_view_bounds.RoundIn() to do the rectangle query.

I think it's a good idea.

flar · 2024-02-22T18:43:41Z

So the basic rule here is that if you want to draw over a platform view, you need to overlap it by more than a single pixel. I can't imagine that anyone would find value in drawing over just a single pixel (wide/tall) sliver on the edge of a platform view. Possibly if they were trying to give it a border, but that would be better accomplished by drawing a more than hairline box around it.

One issue that I think still remains to be seen is whether an adjacent contrasting widget will flicker as you scroll it next to a platform view. I don't think that will be visible on platforms which use a whole number for the DPR (such as Apple devices?) but that should be tested to be sure. It might come into play on platforms that have non-integer DPRs, but this change is only being proposed for iOS. Do we potentially also want to make the same change to the other platform embedders?

hellohuanlin · 2024-02-22T19:07:50Z

I can't imagine that anyone would find value in drawing over just a single pixel (wide/tall) sliver on the edge of a platform view.

Strongly agreed!

One issue that I think still remains to be seen is whether an adjacent contrasting widget will flicker as you scroll it next to a platform view. I don't think that will be visible on platforms which use a whole number for the DPR (such as Apple devices?) but that should be tested to be sure.

Will do. I haven't seen flicker as of this change for now, but will test more.

Do we potentially also want to make the same change to the other platform embedders?

Yes I think so

flar · 2024-02-22T20:21:21Z

flow/embedded_views.h

+  // TODO(hellohuanlin): iOS only for now, but we should try it on other
+  // platforms. We should deprecate the above `region` function if we migrate
+  // all platforms to use this function.
+  DlRegion roundedInRegion(const SkRect& query) const {


Perhaps have the region() method take an SkIRect and let the caller decide how to turn their SkRect into the appropriate pixel query?

This should be a common functionality across platforms. I'd prefer to keep the logic here so we can try it on other platforms, rather than duplicate the logic.

I guess my thinking was that this class should not be imposing rounding logic assumptions on the callers. It has "pixel based" data to share and should expect "pixel based" queries from the callers.

But this is just a nit suggestion...

Gotcha. I do see pros and cons. Worth to think about.

The eventual name should just be "region" if we consolidate.

flar · 2024-02-22T20:44:24Z

I think you need to rebase to ToT due to the infra misconfiguration causing the ci.yaml step to fail.

hellohuanlin · 2024-02-22T20:46:53Z

I think you need to rebase to ToT due to the infra misconfiguration causing the ci.yaml step to fail.

Oh this is just a draft PR that I open for early discussion purpose. I haven't added test etc and I still need to play around when new benchmark projects and toolings are ready.

flar

LGTM. I added a nit about the eventual name of the consolidated method, not sure if it really needs a direct mention in the comments. I'll leave that up to you.

testing/scenario_app/lib/src/platform_view.dart

jonahwilliams

LGTM

jonahwilliams · 2024-03-21T19:24:29Z

I think this should also fix flutter/flutter#138656, where we end up creating a fullscreen blur due to the 1px overlay layer.

flar

Approving, but I'd like to see the test case nesting made more straight-forward so it is more readable for future maintenance.

testing/scenario_app/lib/src/platform_view.dart

hellohuanlin · 2024-03-21T20:50:16Z

I think this should also fix flutter/flutter#138656, where we end up creating a fullscreen blur due to the 1px overlay layer.

Let me take a look.

…tter/engine#50637)

…145578) flutter/engine@e2f324b...5a12de1 2024-03-21 41930132+hellohuanlin@users.noreply.github.com [ios][platform_view][performance] overlay intersection (flutter/engine#50637) 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 jonahwilliams@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://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

zanderso · 2024-03-22T19:13:13Z

SkiaPerf noted some improvements on this PR: https://flutter-flutter-perf.skia.org/e/?begin=1710569785&end=1711132808&keys=Xfcc3b437ed855c530c4746be51cac5da&requestType=0&selected=commit%3D39955%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253D90th_percentile_frame_rasterizer_time_millis%252Ctest%253Dplatform_views_scroll_perf_ad_banners__timeline_summary%252C&xbaroffset=39955

github-actions bot added the platform-ios label Feb 14, 2024

hellohuanlin changed the title ~~[DRAFT][ios][platform_view][performance] overlay interception~~ [DRAFT][ios][platform_view][performance] overlay intersection Feb 14, 2024

hellohuanlin requested review from jmagman and jonahwilliams February 21, 2024 01:22

jonahwilliams reviewed Feb 21, 2024

View reviewed changes

flar requested changes Feb 21, 2024

View reviewed changes

hellohuanlin force-pushed the platform_view_overlay_intersection branch from f68ea30 to 0fa06bf Compare February 22, 2024 19:56

flar reviewed Feb 22, 2024

View reviewed changes

hellohuanlin force-pushed the platform_view_overlay_intersection branch from 0fa06bf to 99943fc Compare March 20, 2024 00:42

flar approved these changes Mar 20, 2024

View reviewed changes

flar reviewed Mar 20, 2024

View reviewed changes

testing/scenario_app/lib/src/platform_view.dart Outdated Show resolved Hide resolved

flar reviewed Mar 20, 2024

View reviewed changes

testing/scenario_app/lib/src/platform_view.dart Outdated Show resolved Hide resolved

flar reviewed Mar 20, 2024

View reviewed changes

testing/scenario_app/lib/src/platform_view.dart Show resolved Hide resolved

hellohuanlin changed the title ~~[DRAFT][ios][platform_view][performance] overlay intersection~~ [ios][platform_view][performance] overlay intersection Mar 21, 2024

hellohuanlin marked this pull request as ready for review March 21, 2024 18:39

hellohuanlin requested a review from jonahwilliams March 21, 2024 19:22

jonahwilliams approved these changes Mar 21, 2024

View reviewed changes

flar approved these changes Mar 21, 2024

View reviewed changes

testing/scenario_app/lib/src/platform_view.dart Show resolved Hide resolved

hellohuanlin added 9 commits March 21, 2024 15:00

[platform_view]use rounded in region to avoid unnecessary overlay layer

4f8494a

add comment on single pixel overlay

7b408e1

scenario tests

ce27f4b

revert pixel change for scneario test

26bcc7a

do not hard code scale

052a651

comment

e0ff93e

more readable test case

b0ec32c

fix const dart

8d2ee76

clean up pop logic

5a81c3f

hellohuanlin force-pushed the platform_view_overlay_intersection branch from 5b26a0c to 5a81c3f Compare March 21, 2024 22:00

hellohuanlin added the autosubmit Merge PR when tree becomes green via auto submit App label Mar 21, 2024

auto-submit bot merged commit 5a12de1 into flutter:main Mar 21, 2024
28 checks passed

engine-flutter-autoroll mentioned this pull request Mar 22, 2024

Roll Flutter Engine from e2f324beac3b to 5a12de1beab7 (1 revision) flutter/flutter#145578

Merged

engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Mar 22, 2024

5a12de1be [ios][platform_view][performance] overlay intersection (flu…

fdf36fa

…tter/engine#50637)

[ios][platform_view][performance] overlay intersection #50637

[ios][platform_view][performance] overlay intersection #50637

Conversation

hellohuanlin commented Feb 14, 2024 • edited by jmagman Loading

Pre-launch Checklist

hellohuanlin commented Feb 21, 2024 • edited Loading

jonahwilliams left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hellohuanlin commented Feb 21, 2024 • edited Loading

flar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

flar commented Feb 21, 2024

knopp commented Feb 21, 2024 • edited Loading

hellohuanlin commented Feb 21, 2024 • edited Loading

knopp commented Feb 21, 2024 • edited Loading

knopp commented Feb 21, 2024 • edited Loading

hellohuanlin commented Feb 21, 2024 • edited Loading

knopp commented Feb 21, 2024

jonahwilliams commented Feb 21, 2024

hellohuanlin commented Feb 21, 2024 • edited Loading

hellohuanlin commented Feb 21, 2024

knopp commented Feb 21, 2024

knopp commented Feb 21, 2024

hellohuanlin commented Feb 22, 2024 • edited Loading

flar commented Feb 22, 2024

flar commented Feb 22, 2024 • edited Loading

hellohuanlin commented Feb 22, 2024

flar commented Feb 22, 2024 • edited Loading

hellohuanlin commented Feb 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

flar commented Feb 22, 2024

hellohuanlin commented Feb 22, 2024

flar left a comment

Choose a reason for hiding this comment

jonahwilliams left a comment

Choose a reason for hiding this comment

jonahwilliams commented Mar 21, 2024

flar left a comment

Choose a reason for hiding this comment

hellohuanlin commented Mar 21, 2024

zanderso commented Mar 22, 2024

hellohuanlin commented Feb 14, 2024 •

edited by jmagman

Loading

hellohuanlin commented Feb 21, 2024 •

edited

Loading

hellohuanlin commented Feb 21, 2024 •

edited

Loading

knopp commented Feb 21, 2024 •

edited

Loading

hellohuanlin commented Feb 21, 2024 •

edited

Loading

knopp commented Feb 21, 2024 •

edited

Loading

knopp commented Feb 21, 2024 •

edited

Loading

hellohuanlin commented Feb 21, 2024 •

edited

Loading

hellohuanlin commented Feb 21, 2024 •

edited

Loading

hellohuanlin commented Feb 22, 2024 •

edited

Loading

flar commented Feb 22, 2024 •

edited

Loading

flar commented Feb 22, 2024 •

edited

Loading