Made a way to turn off the OpenGL operations on the IO thread for backgrounded apps - #13908

I don't think this is right, even for iOS. We shouldn't be using .detached here and even .paused can give us a false signal on iOS (if we just lost the VC but haven't actually gone to background). It seems like we have a bug where only the FlutterViewController is subscribing to the app lifecycle events but not the FlutterEngine. I think what we really want is to move some of that logic into FlutterEngine. /cc @xster who recently did work on that and might know something I'm missing.

I would find it clearer to name this something like is_gpu_access_allowed_switch. We could then expose a way to set that for the embedders, so that an individual embedder can decide to set it to false when needed (on iOS, only when the app is definitely going to background, as opposed to just losing the VC; on other platforms, status quo for now).

I believe this would also still cause the crash in the following scenario:

• Create engine with no VC
• Have engine run Dart code that asks to decode an image after some delay e.g.:

Future<void> main async {
  await Future<void>.delayed(const Duration(seconds: 5));
  // code to decode an image
}

• Before that delay, background the app after the engine has had time to start the Dart code but before the image decoding reaches a GL call
• I don't believe this code path will have executed at all, and the switch has been defaulted to false (right?).

So I think for this patch we really should have the FlutterEngine listening for applicationWillResignActive and applicationBecameActive. and then it could set the value of this switch specifically in those cases.

That sounds fine. I just realized this morning that I wasn't activating the switch on the platform thread so moving the logic up the stack will get both what you want and get me back on the platform thread.

Done.

Yes, good point from @dnfield (and the new implementation looks reasonable too).

This reasons the framework (currently the engine) wanting to stop scheduling a frame (flutter/flutter#45131) is indeed not a 1:1 match with the reasons the engine wanting to block an outgoing frame.

I don't know why GitHub ate my comment about the mutex, so adding it back in:

Please use the shared exclusive mutex in //flutter/fml/synchronization/shared_mutex.h with a SharedLock here and UniqueLock in SetSwitch.

Discussed offline, scoped_lock makes sense. It avoids the overhead of a read-write lock when we don't need it and the overhead of a virtual function.

Nit: You missed removed the extra scope here.

Done

Still neither here not there, either use the pass by value if using the convention before #13975 lands or const refs if after.

Discussed offline. I was working under the false idea that you had to explicitly create rvalues and that this would force users to pass in rvalues. I moved this over to const ref to match the other code.