started providing the GPU sync switch to external view embedders

[gaaclarke]

Description

External view embedders may be doing work on the GPU and they have to make sure they don't do so while the app is in the background.

I considered first making this a parameter to the ios_external_view_embedder but decided against it because:

1. If this external embedder needs to consider the gpu switch than another implementation of the ExternalViewEmbedder would probably have to consider it.
2. Creation of the iOS external view embedder happens before the shell is created so we'd have to use a setter instead of a constructor argument and there is the chance to introduce bugs.

Related Issues

fixes flutter/flutter#69642

Tests

I added the following tests:

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the contributor guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I read and followed the C++, Objective-C, Java style guides for the engine.
• I read the tree hygiene wiki page, which explains my responsibilities.
• I updated/added relevant documentation.
• All existing and new tests are passing.
• I am willing to follow-up on review comments in a timely manner.

Reviewer Checklist

• I have submitted any presubmit flakes in this PR using the engine presubmit flakes form before re-triggering the failure.

Breaking Change

Did any tests fail when you ran them? Please read handling breaking changes.

• No, no existing tests failed, so this is not a breaking change.
• Yes, this is a breaking change. If not, delete the remainder of this section.
  • I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
  • I got input from the developer relations team, specifically from: Replace with the names of who gave advice
  • I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

[cyanglaz]

Code looks good. I have no clue what does gpu_disable_sync_switch do and how it works. Let's add another reviewer who knows this better?

[chinmaygarde]

cc @jason-simmons

[jason-simmons]

Is the SetIfTrue handler necessary? result is already set to false by default

[gaaclarke]

Nope, it shouldn't be necessary. Once I get things sorted out I'll try removing it.

[gaaclarke]

Oh, shoot I forgot to do this before it landed. I was in a rush. It's probably not a big deal, if you want it gone I can do it in a separate PR. Sorry.

[blasten]

@gaaclarke , @cyanglaz - I came across this change. Do you know why not clearing the current pending raster tasks in Shell.OnPlatformViewDestroyed?

Shell.OnPlatformViewDestroyed is called from the same lifecycle event applicationWillResignActive

engine/shell/platform/darwin/ios/framework/Source/FlutterViewController.mm

Line 707 in a598f23

[self surfaceUpdated:NO];

[gaaclarke]

@blasten If we synchronously flushed all outstanding GPU tasks on the raster thread for the external view embedder when we got the ResignActive notification and guaranteed that it will never attempt another GPU tasks until the app has become active again that would be a valid way to solve this issue, too. Is that what you are asking?

[blasten]

@gaaclarke yep. @cyanglaz mentioned that the crash would happen here https://github.com/flutter/engine/blob/master/shell/common/rasterizer.cc#L438 because we teared down the surface from the link I mentioned above.

It sounds like we need a primitive to ensure that all pending tasks are flushed and that the queue is disabled.

[gaaclarke]

@blasten Check out the issue this PR addresses, the stacktrace of the crash is there. It's from the external view embedder executing GPU operations. This PR causes the platform thread to wait for GPU operations to execute before exiting, then turns them off atomically. Any other attempts at creating frames in the background will be dropped. It's the same mechanism we use elsewhere like the decoding of images on background threads.

[blasten]

right. I guess my question is more about defining some primitives that work well across platforms. Do you know if we need to do this for Android too?

[gaaclarke]

I believe iOS is the only platform we currently support that has the requirement that GPU access may be blocked. Android at least doesn't crash, for energy reason we might want to disable GPU operations in the background if the operating system isn't already handling that gracefully.