Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

@cyanglaz
Copy link
Contributor

  1. This PR makes the OverlayView(which is masked by OverlayWrapper) to be at the correct frame. The new frame of the OverlayView is the same as the FlutterView. Because the Overlay is at the correct frame, we don't need to add a transform matrix to the skia canvas, so that skia doesn't draw off canvas.

This somehow fixes the flickering issue in flutter/flutter#103076, I'm not sure the exact reason behind it but it seems like it is related to Skia trying to draw off canvas.

  1. Makes the thread merging happen at the end of the last frame on raster thread. This prevents a new frame starts on the raster thread before the thread merging is completed.

This fixes some occasional unsynchronized frame, also observed in flutter/flutter#103076

I have observed another thread synchronization issue during thread un-merging. It seems a little more complicated so I'll create a separate PR for it .

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 Hixie said 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.

@flutter-dashboard
Copy link

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@cyanglaz cyanglaz force-pushed the platform_view_overlay_frame branch from cae8d76 to 63ed36f Compare May 11, 2022 16:53
@cyanglaz cyanglaz requested review from blasten and iskakaushik May 11, 2022 19:31
@cyanglaz
Copy link
Contributor Author

@zanderso Here's the fix for the PlatformView flickering issue. How do mark this to be a CP candidate?

@zanderso
Copy link
Member

@zanderso
Copy link
Member

This will be easier to approve for a cherry-pick if it can have a test.

@cyanglaz
Copy link
Contributor Author

This will be easier to approve for a cherry-pick if it can have a test.

I'm adding tests now. Building the test locally took some time and I just put the PR up before it :)

@cyanglaz
Copy link
Contributor Author

@iskakaushik Do you mind take a look at code for both update?
@blasten Do you mind take a look at the code, specifically related to unobstructed platform views?

// Set the size of the overlay view.
// This size is equal to the device screen size.
overlay_view.frame = flutter_view_.get().bounds;
overlay_view.frame = [flutter_view_.get() convertRect:flutter_view_.get().bounds
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have you seen any side effects when the frame size is changed in every frame? Try running https://github.com/flutter/flutter/tree/195a1cc413bde5f7c1d194204608c4bc20659124/dev/benchmarks/platform_views_layout with this change. That test has an animated container that should cause this value to change after each frame https://github.com/flutter/flutter/blob/195a1cc413bde5f7c1d194204608c4bc20659124/dev/benchmarks/platform_views_layout/lib/main.dart#L121

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I ran the benchmarks, there doesn't seem to be significant difference:

With my change:

  "average_frame_build_time_millis": 0.2156956521739131,
  "90th_percentile_frame_build_time_millis": 0.27,
  "99th_percentile_frame_build_time_millis": 0.316,
  "worst_frame_build_time_millis": 0.326,
  "missed_frame_build_budget_count": 0,
  "average_frame_rasterizer_time_millis": 4.833215053763439,
  "90th_percentile_frame_rasterizer_time_millis": 6.668,
  "99th_percentile_frame_rasterizer_time_millis": 7.84,
  "worst_frame_rasterizer_time_millis": 9.612,
  "missed_frame_rasterizer_budget_count": 0,

master:

  "average_frame_build_time_millis": 0.21664516129032269,
  "90th_percentile_frame_build_time_millis": 0.286,
  "99th_percentile_frame_build_time_millis": 0.305,
  "worst_frame_build_time_millis": 0.357,
  "missed_frame_build_budget_count": 0,
  "average_frame_rasterizer_time_millis": 4.918989130434783,
  "90th_percentile_frame_rasterizer_time_millis": 6.905,
  "99th_percentile_frame_rasterizer_time_millis": 8.33,
  "worst_frame_rasterizer_time_millis": 9.434,
  "missed_frame_rasterizer_budget_count": 0,

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did you see any issue in general? if you run the app, and play with it? e.g. Could this change introduce jank or glitches?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, I didn't see this change introduce new janks or glitches.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

friendly ping @blasten
Did you have other suggestions/comments?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no more suggestions. Thanks for looking!

@cyanglaz
Copy link
Contributor Author

cyanglaz commented May 12, 2022

@zanderso Looks like the original issue on the app was magically fixed and the issue was closed. Since it is not a regression and requires a specific device/steps to reproduce, I would suggest to not cherry-pick. WDTY?

@zanderso
Copy link
Member

I'm not sure that I trust that it was magically fixed. Is there a version of the app where it repros locally for you without your fix?

Chris Yang added 2 commits May 12, 2022 13:00
draft

test code

format

revert

revert testing code

cleanup

clea nup

revert

scenario test for overlay view frame

test thread merge at end frame

add scenario tests

fix typo
@cyanglaz cyanglaz force-pushed the platform_view_overlay_frame branch from 56eb0de to eb94a6b Compare May 12, 2022 20:07
@cyanglaz
Copy link
Contributor Author

cyanglaz commented May 12, 2022

I'm not sure that I trust that it was magically fixed. Is there a version of the app where it repros locally for you without your fix?

I wasn't able to repro the same exact issue they were experiencing. Not with local build, flutter stable/master, nor the TestFlight build.

Mine looks a little bit different as shown in flutter/flutter#103076 and it repros even in stable. Their video capture, however, does look like some sort of syncing issue between PlatformView and Overlay. Since the fix on the thread merging in this PR fixed the flickering issue that I was experiencing (caused by frames not synchronized during thread merging), I guess the same code might fix the issue they saw.

I asked them to test their app with this PR and see if it fixes the glitch that they saw. but it seem they couldn't reproduce the issue anymore.

@zanderso
Copy link
Member

Got it. Not sure I completely follow the timeline, but if the issue was possibly introduced by the 120Hz change, then we should queue this up for a cherry-pick. Otherwise, that is if it's just a fix for a pre-existing issue, then I don't think we need a cherry-pick.

@iskakaushik
Copy link
Contributor

This wasn't introduced by the 120hz work, rendering at high frame rates only made a previously present issue more apparent. I was able to reproduce this with the 120hz change reverted as well.

@cyanglaz
Copy link
Contributor Author

cyanglaz commented May 12, 2022

Got it. Not sure I completely follow the timeline, but if the issue was possibly introduced by the 120Hz change, then we should queue this up for a cherry-pick. Otherwise, that is if it's just a fix for a pre-existing issue, then I don't think we need a cherry-pick.

Yes, the issue was not related to 120Hz. The issue happens randomly, I think it is a little more reproducible with 120hz enabled just because we draw more frames with 120Hz.
And sounds good, let's not cherry-pick this. I'm going to lower the priority of the issue.

@cyanglaz
Copy link
Contributor Author

cyanglaz commented May 12, 2022

Also note that the issue only happens on iPhone 13pro. I'm not sure why, but It is possible that Skia drawing outside of the canvas worked in previous iPhones but not the iPhone 13pro.

@zanderso
Copy link
Member

Chatted with folks offline. It sounds like a cherry-pick isn't needed. Is this ready to land, though?

@cyanglaz
Copy link
Contributor Author

friendly ping @iskakaushik for review

void IOSExternalViewEmbedder::EndFrame(bool should_resubmit_frame,
fml::RefPtr<fml::RasterThreadMerger> raster_thread_merger) {
TRACE_EVENT0("flutter", "IOSExternalViewEmbedder::EndFrame");
FML_CHECK(platform_views_controller_);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this deleted?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a CHECK, so it is essentially crashing the app if platform_views_controller_ is null, which is exactly what the next will do.

I think this check shouldn't be here at all.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's better to fail with a reasonable error message than null pointer dereferencing, right?

Is there a situation in which platform_views_controller_ can become null? Or do we check during initialization?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's any reason it would happen in the current code, but it might happen if rasterizer's logic changes.

Good point to have a failing message, I will add the check back and add a failing message.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it but not sure what additional message to add that would be useful. We assume platform_views_controller_ is not null here and it crashes if it is null.

I could add something like "platform_views_controller_ must not be null" but it is redundant as crashing at latform_views_controller_->EndFrame(should_resubmit_frame, raster_thread_merger); would self-explained it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

friendly ping @iskakaushik

// Eventually, the frame is submitted once this method returns `kSuccess`.
// At that point, the raster tasks are handled on the platform thread.
CancelFrame();
raster_thread_merger->MergeWithLease(kDefaultMergedLeaseDuration);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is moved to EndFrame to ensure the threads are merged at the very end of the frame.

Copy link
Contributor

@iskakaushik iskakaushik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jmagman
Copy link
Member

jmagman commented May 31, 2022

@cyanglaz is this ready to merge?

Copy link

@blasten blasten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants