-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add safer borrowed handles #110
Conversation
I'd be happy to have you on the team but I don't think I personally have permissions to edit the team. One of the higher level rust-windowing admins should be able to add you. |
Done. |
Thanks @kchibisov! I'll merge this patch in. |
@notgull can you also do a follow up PR to put this in the changelog so i can just pull the latest and release the patch once I'm free later? |
Hey, sorry for being late to the party here. I'm just trying to follow the recent changes here and get a clearer understanding. Here are a few initial comments I made on related issue #111 where I was pinged #111 (comment) I'm not sure that there was a safety issue on Android here - assuming a valid reference to an Android apps need to be aware to recreate render surfaces when they resume but it was possible to handle that safely with the previous raw-window-handle + Winit API (E.g. here are some examples that work on Android and are also portable to desktop window systems: https://github.com/rust-mobile/rust-android-examples) I'm maybe missing a full understanding currently of how consumers of this are intended to handle the introduced Are consumers now required to poll when a display handle becomes active/inactive and maybe automatically re-create surfaces when transitioning to active, and NOP when inactive? My gut feeling at the moment is that Android applications should be driven by the app lifecycle events directly and instead of having handle consumers poll for lifecycle changes and automatically re-creating surfaces it seems like we should give out new handles to consumers when resumed/re-activated. There can surely be lots of, potentially app-specific, details involved in creating graphics API surfaces from a handle so I'm very unclear if the implication with this design is that consumers polling for |
The theory is that consumers would actually hold references to the underlying There isn't really any kind of "polling" here; when you want to access the window you check whether or not the application is suspended. While you hold the window handle, the application won't enter the suspended state until you stop holding it.
I'm not sure that the reference stays valid forever, as the docs say:
The docs also seem to imply that the pointer could change in between the |
This sounds problematic. As mentioned in #111 (comment) the typical graphics API doesn't "want to access the window" to check whether it may be suspended at random: this (creating a The only odd case for add-hoc getting the window/handle is to read the size, or call |
I'm not sure how this will be manageable. If you create a surface, such as an EGLSurface that's effectively holding on to the window handle indefinitely. Creating a surface is going to hold a reference to the E.g. see docs for creating an Vulkan surface which say how it takes a reference to the
The You could e.g. call Your app won't work properly if you do just continue trying to use the window after the Considering how the Surface Java API is a thin layer over As another point of reference it's also possible to acquire an At least anecdotally I can also say that when I've accessed |
The idea is that, before you call any let _guard = match self.window_type.window_handle() {
Err(HandleError::Inactive) => return Err(MyError::WindowWasInactive),
Ok(handle) => {
if handle != self.raw_window_handle_thats_registered_in_gl_or_whatever {
return Err(MyError::UserDidntDropUsWhenWeRequestedIt);
}
handle
}
}; The idea is that:
As far as I know, this is the best way of delivering the notification that the window is suspended in a way that can be done 100% safely by the end user. (Now that I think about it, the above code might be useful to add to
This is an interesting point that I wasn't aware of. In this case, I think the current API can accommodate this, though; we just add documentation to the
I think that the system I mentioned above should counteract this. |
I'm not sure that it does - or I didn't follow how it does. this protocol is concerned with (not) letting the app touch the If an I don't see how the transient guard will be able to affect the retention of surface references passed on to C APIs that are going to be held for long periods of time. What's missing is that Android apps need to go and explicitly drop all graphics surfaces that could be holding on to an |
For completeness we deduced that holding on to |
Pretty much a copy-paste of my
window-handle
repo to this crate. See here for rationale.By the way, would it be possible to add me to the @rust-windowing/raw-window-handle team so that I can maintain this code?