Possible solution to keep created surface consistent

rust-windowing / winit

Window handling library in pure Rust

https://docs.rs/winit/

Apache License 2.0

4.55k stars 876 forks source link

Possible solution to keep created surface consistent #3695

Open ztlwk opened 1 month ago

ztlwk commented 1 month ago

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 commented 2 days ago

See https://github.com/rust-windowing/winit/issues/3699. Cc @MarijnS95.

MarijnS95 commented 2 days ago

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 https://github.com/rust-windowing/winit/issues/2337?

daxpedda commented 2 days ago

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 commented 1 day ago

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