Possible solution to keep created surface consistent

[ztlwk]

Description

Motivation

This issue aims for the following topics:

• Users have to self-reference the window handle to the surface, which can be hard to implement.
• The created surfaces must be dropped by user when the the app was suspended, and we may somehow "enforce" it.
• Owning the optional window and surface in every update can have lifetime issues, and we may make some platform-specific changes to make it "consistent" to user.
• The "optional" surface problem seemed to be only present in Android.

I am unsure about whether winit should absolutely do some changes for them, but this issue is opened for the discusssions about the possible solutions and winit api design.

Proposed Change

• Require the user to implement a "bridge" type, which owns the corresponding surface, and gets dropped and recreated by winit when being suspended in Android.
• Make the "bridge" type or ApplicationHandler trait include the window recreation logic, so winit can recreate the window and own it, which assured the users to have a "window" in every update.

Relevant platforms

Android

[daxpedda]

See #3699.
Cc @MarijnS95.

[MarijnS95]

Seen this while reading #3699, and I'm more inclined to pursue that issue. For one, this issue doesn't describe a problem statement, so it's hard to understand what kind of issue or design problem the author intends this proposed design for.

Maybe this is somewhat loosely related to #2337?

[daxpedda]

I think the goal of OP is that we somehow avoid having to re-create RawWindowHandle.
You indicated in the last meeting that this is possible, because that's how it was in the past, could you clarify the details here?

So my understanding is that Window survives just fine.
RawWindowHandle becomes invalid but not unsafe, e.g. rendering just goes into a black hole but doesn't segfault.

How much exactly of the graphics context is invalidated, how about GPU buffers?
Is it possible for Winit to drape over this fact and "patch" the RawWindowHandle so we can pretend everything's continuing to work? So just notifying the user that the app is now in the background and no rendering will be visible and after resumption everything continues to work just fine.

[ztlwk]

Sorry for the vague description, I have edited it to make it more clear.

[MarijnS95]

So my understanding is that Window survives just fine.

On Android, if we consider Window to be analogous to an Activity (of which we can hackily only have just one currently), yes. The NativeWindow/Surface in Android is "just" its temporary backing buffer (or well, buffer queue / producer end).

---

RawWindowHandle becomes invalid but not unsafe, e.g. rendering just goes into a black hole but doesn't segfault.

rust-windowing/raw-window-handle#111 (comment)

---

How much exactly of the graphics context is invalidated, how about GPU buffers?

Just the Surface and Swapchain in Vulkan terms. In GL your context becomes "uncurrent" (because it can only be current when there's a render target, i.e. a Surface, as far as I understood) but the UBOs should continue to exist?

---

Is it possible for Winit to drape over this fact and "patch" the RawWindowHandle so we can pretend everything's continuing to work? So just notifying the user that the app is now in the background and no rendering will be visible and after resumption everything continues to work just fine.

@daxpedda doing some code/discussion archaeology: such a thing was originally implemented in rust-windowing/raw-window-handle#110 (winit side pending in #2744), and later reverted in rust-windowing/raw-window-handle#126.