Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Impeller] Ensure that overlay surfaces are constructed with wide gamut settings. #48190

Merged
merged 16 commits into from
Nov 21, 2023

Conversation

jonahwilliams
Copy link
Member

@jonahwilliams jonahwilliams commented Nov 17, 2023

Fixes flutter/flutter#138373

When constructing overlay layers when there are platform views, make sure the same pixel format and color space as the main view is used.

Add validation to impeller HAL about blitting different pixel formats.

// If the context supports blitting and the pixel formats are identical,
// blit the offscreen texture to the onscreen texture. Otherwise, draw it to
// the parent texture using a pipeline (slower).
auto src_format = offscreen_target.GetRenderTarget()
Copy link
Member

Choose a reason for hiding this comment

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

Seems like the problem is that the pixel format for the offscreen_target does not match the root_render_target. Can't we just make that the case?

Copy link
Member Author

Choose a reason for hiding this comment

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

Can't we just make that the case

If we dont need the offscreen to be wide gamut, we probably shouldn't take the performance hit, no?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh I see, we do need it. that is what I fixed. We should discuss this next week. If essentially turning wide gamut is really a 4x performance improvement for backdrop blurs then we shouldn't have it on by default

Copy link
Member

Choose a reason for hiding this comment

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

Oh I see, we do need it. that is what I fixed.

No, I meant instead of making a drawing call to replace a blit making sure the blit is always possible.

Copy link
Member Author

Choose a reason for hiding this comment

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

WDYM? If the texture formats don't match the blit isn't possible, that is what I'm doing. There is still a blit if they match.

Copy link
Member

@gaaclarke gaaclarke Nov 17, 2023

Choose a reason for hiding this comment

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

That offscreen texture is one that we create, right? So we should be specifying that it has the same format as the final surface. That's how this stuff originally worked as far as I recall.

Copy link
Member Author

Choose a reason for hiding this comment

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

CreateOffscreen has always used Capabilities.GetDefaultColorFormat(); Do we update that if the app switches into wide gamut?

If we're not doing that, then I think pretty much anything else in the entity_pass will start failing, because it doesn't seem like we've accounted for backdrop filters in with the wide gamut support?

Copy link
Member

Choose a reason for hiding this comment

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

It's been a while since I implemented it. I thought I made sure offscreen buffers were created to match the surface pixel format. If that wasn't the case it seems like we'd see some nasty bugs. At any rate, I think that is the correct fix. Fix the setup of the offscreen buffers, not create a workaround to account for them being setup incorrectly (with added runtime cost).

Copy link
Member Author

Choose a reason for hiding this comment

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

Investigated this and the offscreen format is updated to match, but the overlay surfaces introduced by platforms were not, which is the result of the mismatch.

Copy link
Member

@bdero bdero left a comment

Choose a reason for hiding this comment

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

Yeah this makes sense. Blitting between differently formatted Textures is never valid for Metal. Sometimes this seems to work on newer iOS devices for some format combinations, but some devices may end up outputting fuchsia... LGTM!

Copy link
Member

@gaaclarke gaaclarke left a comment

Choose a reason for hiding this comment

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

Requesting changes until we resolve the question if we can make the blit always work.

// If the context supports blitting and the pixel formats are identical,
// blit the offscreen texture to the onscreen texture. Otherwise, draw it to
// the parent texture using a pipeline (slower).
auto src_format = offscreen_target.GetRenderTarget()
Copy link
Member

Choose a reason for hiding this comment

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

Oh I see, we do need it. that is what I fixed.

No, I meant instead of making a drawing call to replace a blit making sure the blit is always possible.

@jonahwilliams jonahwilliams changed the title [Impeller] dont blit onto wide gamut surface. [Impeller] Ensure that overlay surfaces are constructed with wide gamut settings. Nov 18, 2023
overlay_view.reset([[FlutterOverlayView alloc] init]);
overlay_view_wrapper.reset([[FlutterOverlayView alloc] init]);
CGFloat screenScale = [UIScreen mainScreen].scale;
overlay_view.reset([[FlutterOverlayView alloc] initWithContentsScale:screenScale
Copy link
Member Author

Choose a reason for hiding this comment

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

Not clear to me why these weren't setting screen scale?

Copy link
Member Author

Choose a reason for hiding this comment

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

Also these branches seem pretty much identical...

@jonahwilliams
Copy link
Member Author

Despite the failed builds all tests are now passing locally...

if (available_layer_index_ >= layers_.size()) {
std::shared_ptr<FlutterPlatformViewLayer> layer;
fml::scoped_nsobject<UIView> overlay_view;
fml::scoped_nsobject<UIView> overlay_view_wrapper;

if (!gr_context) {
bool impeller_enabled = !!ios_context->GetImpellerContext();
if (!gr_context && !impeller_enabled) {
Copy link
Member Author

Choose a reason for hiding this comment

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

It seems like the intention of this code was to run when the software backend was enabled, but it was running with Impeller enabled. I don't even know who to FYI, maybe @dnfield @chinmaygarde ?

@jonahwilliams
Copy link
Member Author

ping @gaaclarke / @chinmaygarde

Copy link
Member

@gaaclarke gaaclarke left a comment

Choose a reason for hiding this comment

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

I think this needs an integration test. We have something similar in flutter/dev/integration_tests/wide_gamut_test. Maybe that could just be expanded to create the problem case with platform views and backdrop filters and look for the display p3 red?

This stuff is really easy to break on accident since it requires thinking of multiple flows through the code (wide gamut vs srgb).

impeller/renderer/blit_pass_unittests.cc Outdated Show resolved Hide resolved
impeller/renderer/blit_pass.cc Show resolved Hide resolved
impeller/renderer/blit_pass_unittests.cc Show resolved Hide resolved
@@ -43,6 +45,10 @@ - (UIScreen*)screen {
return UIScreen.mainScreen;
}

- (MTLPixelFormat)pixelFormat {
return _pixelFormat;
Copy link
Member

Choose a reason for hiding this comment

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

Do we need a new ivar? Can't we use self.layer.pixelFormat?

Copy link
Member Author

Choose a reason for hiding this comment

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

the layer ivar isn't exposed, this seemed more restricted.

Copy link
Member

Choose a reason for hiding this comment

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

Right, you should keep your accessor. Just use:

- (MTLPixelFormat)pixelFormat {
  return self.layer.pixelFormat;
}

By duplicating this value we are opening ourselves up to bugs where the layer's pixel format does not match the FlutterView's pixel format.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed, I think!

Copy link
Member

@gaaclarke gaaclarke left a comment

Choose a reason for hiding this comment

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

LGTM, modulo removing the duplicated ivar and filing an issue for a device lab tests, since it can't be included here.

@jonahwilliams
Copy link
Member Author

Integration test is: flutter/flutter#138837

Copy link
Member

@gaaclarke gaaclarke left a comment

Choose a reason for hiding this comment

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

thanks, lgtm!

@jonahwilliams jonahwilliams added the autosubmit Merge PR when tree becomes green via auto submit App label Nov 21, 2023
@auto-submit auto-submit bot merged commit e993a5c into flutter:main Nov 21, 2023
28 checks passed
@jonahwilliams jonahwilliams deleted the fix_wide_gamut_blit branch November 21, 2023 20:30
@bdero
Copy link
Member

bdero commented Nov 21, 2023

Great investigation :)

engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Nov 21, 2023
auto-submit bot pushed a commit to flutter/flutter that referenced this pull request Nov 21, 2023
…138844)

flutter/engine@3179986...90d1ff0

2023-11-21 [email protected] Make `{shell|lib/ui}/...` compatible with `.clang_tidy`. (flutter/engine#48242)
2023-11-21 [email protected] [Impeller] Ensure that overlay surfaces are constructed with wide gamut settings. (flutter/engine#48190)

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://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
@mark8044
Copy link

mark8044 commented Nov 21, 2023

@jonahwilliams
Hi, it looks like this is now merged into master, I'm using the following build:

Flutter 3.17.0-13.0.pre.15 • channel master • https://github.com/flutter/flutter.git
Framework • revision ba433ebb65 (39 minutes ago) • 2023-11-21 17:31:16 -0500
Engine • revision a8e9b8dd56
Tools • Dart 3.3.0 (build 3.3.0-152.0.dev) • DevTools 2.30.0-dev.4

IF SO:
It looks like this does in fact fix the GPU rendering crash we discussed here flutter/flutter#138615

HOWEVER, the app is very slow with alot of jank when scrolling through platform views (I'm using flutter web view to present YouTube videos within a listview). Once the view is scrolled off screen, the jank then becomes minimal

The previous builds of master, using FLTEnableWideGamut off was super fast with only minimal to no jank through the same views.

<key>FLTEnableWideGamut</key>
<false/>

@jonahwilliams
Copy link
Member Author

does turning wide gamut off not improve things after this change?

@mark8044
Copy link

mark8044 commented Nov 22, 2023

does turning wide gamut off not improve things after this change?

Doesn't seem to do much anymore or maybe a minor improvement. But jank is there when scrolling though the webview. The page has some backdrop filters on it

@jonahwilliams
Copy link
Member Author

The performance improvement you observed was likely a fluke caused by the rendering error then.

@mark8044
Copy link

mark8044 commented Nov 22, 2023

The performance improvement you observed was likely a fluke caused by the rendering error then.

Darn, well I enjoyed it while it lasted :)
Still some ways to go with jank it seems

@mark8044
Copy link

mark8044 commented Nov 22, 2023

Here's a strange but highly consistent oddity.

There is 0 jank (smooth as silk) when using the App on an older device (iPhone X) running on iOS 16 (16.2)

The jank however is consistent and easily reproducible on a newer iPhone 13 running on iOS 17

@jonahwilliams
Copy link
Member Author

Is that due to a frame rate difference? 60hz vs 90/120hz? Depending on the model that might be the case. If you are barely hitting 60 fps, the high frame rate device isn't literally twice as fast so you may miss frames at a higher frame rate.

In any case, please consider adding more information such as your own timeline traces (from main) onto the existing issue and I'll investigate more next week.

auto-submit bot pushed a commit to flutter/flutter that referenced this pull request Nov 27, 2023
In flutter/engine#48190 I discovered that overlay surfaces were not constructed with wide gamut settings. This adds a test that will fail until this is fixed.
auto-submit bot added a commit to flutter/flutter that referenced this pull request Nov 27, 2023
Reverts #138837
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
In flutter/engine#48190 I discovered that overlay surfaces were not constructed with wide gamut settings. This adds a test that will fail until this is fixed.
caseycrogers pushed a commit to caseycrogers/flutter that referenced this pull request Dec 29, 2023
…lutter#138844)

flutter/engine@3179986...90d1ff0

2023-11-21 [email protected] Make `{shell|lib/ui}/...` compatible with `.clang_tidy`. (flutter/engine#48242)
2023-11-21 [email protected] [Impeller] Ensure that overlay surfaces are constructed with wide gamut settings. (flutter/engine#48190)

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://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
caseycrogers pushed a commit to caseycrogers/flutter that referenced this pull request Dec 29, 2023
In flutter/engine#48190 I discovered that overlay surfaces were not constructed with wide gamut settings. This adds a test that will fail until this is fixed.
caseycrogers pushed a commit to caseycrogers/flutter that referenced this pull request Dec 29, 2023
)

Reverts flutter#138837
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
In flutter/engine#48190 I discovered that overlay surfaces were not constructed with wide gamut settings. This adds a test that will fail until this is fixed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
autosubmit Merge PR when tree becomes green via auto submit App e: impeller platform-ios
Projects
No open projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Wonderous gets frozen after adding an item to the collection
4 participants