rust-windowing
Emit `destroy_surfaces()` on every platform before `LoopDestroyed` for surface-cleanup feature parity?
As we have done in #2331 by emitting Resumed on every platform somewhere after the loop starts (for platforms that don't have an explicit point/callback where this should happen) to consistently implement surface creation, we should likely do the same with Suspended on loop shutdown for platforms that don't have an explicit callback here. This will allow implementers to perform surface destruction in a single consistent place too.
I'm currently improving a random winit sample to utilize these events, and the implementation becomes clumsy when having surface destruction in both LoopExiting and Suspended. It might even conflict with WindowEvent::Destroyed.
On Android I'm not yet sure if triggering a loop exit would terminate the Android app in such a way that surface destruction (== Suspended) is raised prior to LoopExiting anyway.
Side-note: Android supports multiple windows, and once the backend crates handle that properly perhaps Resumed needs to be moved to a WindowEvent, and Suspended will become Destroyed?
This affects Web as well, I'm in favor of this!
Side-note: Android supports multiple windows, and once the backend crates handle that properly perhaps
Resumedneeds to be moved to aWindowEvent, andSuspendedwill becomeDestroyed?
Can't talk about other backends, but at least on Web this is weird because a Window doesn't represent an actual window, but just a canvas (see #696, which might attempt to change this, though I'm not sure how this affects the logic of all this for other backends, e.g. Android). So a single Window can't be independently suspended.
On Android a winit::Window should - theoretically when we fix everything - represent an Activity, which really is analogous to a desktop window. These typically have only one drawable surface for native apps/games [^1].
When one goes out of view and is paused (because activities are mostly fullscreen) their backing surface could be Suspended, so that might not map to Web then. But we could still start with consistently emitting the event "somewhere" before LoopExit.
One thing I haven't really looked into, but which we'll need to is loop consistency. For example on Android, do we use the proper APIs to destroy the app and receive a NativeWindowDestroyed (resulting in winit::Event::Suspended) before exiting the loop, or should we emulate it if the window is still there?
[^1]: But you could definitely have more, i.e. one can create Surfaces in Android's "view root" that are all individual raw-"window"-handles that can be bound to GL/Vulkan Surfaces/Swapchains and rendered to, as individual buffer producers that are sent to the compositor.