-
-
Notifications
You must be signed in to change notification settings - Fork 477
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
Switch from android_glue
to ndk-glue
and remove outdated lifecycle handing
#1411
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah we "fixed" this in
ndk-glue
but it relies on the caller/user (winit) to hold a lock on thewindow
and release it after its done all its cleanup upon receivingWindowDestroyed
. Looks like at leastwinit
'sfn raw_window_handle() -> RawWindowHandle
doesn't do that yet, butnew_windowed()
here calls directly intondk_glue::native_window()
where we can implement that 🎉It should perhaps be part of this PR though (to store
nwin
inside the context).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like #1320 reported this too, which we can probably close as "outdated" when this is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw the API is currently annoying with an
Option
inside the lock, I'm thinking about changingndk-glue
toparking_lot
which allows mapping - in this case specifically for transmuting - theOption
out of theRWLockReadGuard
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Putting the
RwLockGuard
inAndroidContext
fails to compile because it is notSync
:Unless I'm misunderstanding your suggestion? Any ideas how to fix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're not misunderstanding my suggestion, it's just a little oversight that I haven't checked further than "this lock guard must be held in some way" and now that you actually try it, see that
glutin
requires its context to beSend
/Sync
.My gut feeling says that
glutin
relies on the (EGL) context is internally synchronized (hence safe to not onlySend
to a different thread, but also access from multiple threads concurrently (Sync
) without locking on the Rust side). A lock guard is obviously not, so it seems like we'll have to wrap the lock guard inside aMutex
🤭. Logically that doesn't solve the requirement forSend
though, maybe those locks fromparking_lot
can be moved into a different thread?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference, the nomicon nicely explains why lock guards are not
Send
:https://doc.rust-lang.org/nomicon/send-and-sync.html
Looks like
parking_lot
supports sending a lock guard though, as long as we enablesend_guard
: https://github.com/Amanieu/parking_lot#usageAt this point it feels like we might put this issue on ice, and solve it when we get to it - as I'd like to address it in
winit
as well and anyway needparking_lot
to be able to map a lock guard and get rid of the innerOption<>
.EDIT: If we do skip this (I'm out of ideas bar migrating
ndk-glue
toparking_lot
), please put aTODO
comment in the code here to explain that we should really hold on to the lock even if the context is moved to a different thread.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jamienicol Here you go:
rust-mobile/ndk#282
jamienicol/glutin@ndk-glue...MarijnS95:ndk-glue-native-window-lock
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need to figure out something with the versioning - I had to do some
patch
hacks to get everything in the dependency chain (winit
) to use the samendk
andndk-glue
. But that's after everyone is content with this idea :)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw I've added this to
winit
in rust-windowing/winit#2307 to make the lock held at least as long as until afterwinit
users processed and returned fromEvent::Suspended
. With that in this becomes less of an issue but it still feels right to hold the lock at exactly the same place where the "consumer" of the window - an EGL window surface - is lifecycle-managed. However, given that we don't really help the user yet with lifetime management given the removal ofset_suspend_callback
, we should just get your PR merged without solving this one and I'll take it on later.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been having even more thoughts about this (rust-windowing/winit#2307 (comment)), and I don't think
glutin
should hold the lock for this bit of the API but depend onwinit
to do it (rust-windowing/winit#2307).Then, with that squared away (though we can just "trust" the surface is safe for now since that's what everyone is doing and works "okay enough", until the next
winit
release with my PR in)glutin
doesn't - shouldn't - usendk_glue
directly at all.winit
usesraw-window-handle
to expose these details, andglutin
can simply use it directly:MarijnS95@baaf31a
(I've added the locks to
winit
with that in mind: people will use thatraw-window-handle
interface and never see nor know about the Android lock directly).In fact we can use this to our advantage to unify
glutin
to use this "generic" way to communicate window-handle pointers around and create GL contexts on it, that's how it's done for Vulkan at least: https://github.com/ash-rs/ash/tree/master/ash-window (out of scope for this PR).