Glutin0.23 android

[dvc94ch]

• Tested on all platforms changed
• Compilation warnings were addressed
• cargo fmt has been run on this branch
• cargo doc builds successfully
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

[goddessfreya]

I've taken a quick look at the PR, but I haven't tested it yet.

[goddessfreya]

To handle the android lifetime cycle thing, can't we just have users drop the Surface and recreate it with new_existing when their application resumes? Is that not like the whole point of new_existing? Why does glutin have to drop it internally when the users can drop it themselves? I think this would be a better solution than platform-specific functions or weird callback setting functions on glutin_interface.

[dvc94ch]

actually if all platforms emit Suspend Resume in winit and the glutin api gains a Surface::<Window>::build_window() -> Window, not sure about other platform's requirements, I think it would be neat.

[goddessfreya]

Are you suggesting something like this? I'm not very pleased with this solution, but maybe I missunderstood. glutin::platform_impl::Config and winit::platform_impl::EventLoop must be Clone.

Ah, well, glutin::platform_impl::Config should be clone. I marked the ones in src/api/{glx,egl}.rs as such, but forgot to mark the types in src/platform_impl/unix/*, so oops. I've updated the sendsync test to also check for clone.

Meanwhile, you don't need an winit::platform_impl::EventLoop, but instead an &winit::platform_impl::EventLoopWindowTarget, which is the second param that winit passes to the run closure, so no need to clone the eventloop.

I should also note that dropping Surf automatically makes it not current, so you don't need the make_not_current in Suspended.

I guess if there was a Surface::<Window>::build_window() -> Window and Surface::<Window>::new() was implemented as (Self::build_window(), Self::new_existing()) it would be less weird.

This sounds like an excellent idea, now that I come to think of it. Yeah, we should do that and then platforms don't have to implement new and instead only new_existing.

actually if all platforms emit Suspend Resume in winit and the glutin api gains a Surface::::build_window() -> Window, not sure about other platform's requirements, I think it would be neat.

Yeah, should be fine on GLX and EGL, as, like I mentioned above, that is what was intended. Off my limited knowledge of how WGL works, I can't imagine anything will go wrong. No clue about cocoa though.

[goddessfreya]

Are these returns necessary?

[goddessfreya]

Minor doc nitpick. Otherwise, this PR is only waiting on the appropriate winit changes :D

[dvc94ch]

I rebased the changes and I think you can merge all except the last commit which is specific to the winit changes. That way I don't hold up other platform implementations.

[goddessfreya]

Okay, one last thing (I swear): is this comment still up to date?

https://github.com/rust-windowing/glutin/pull/1274/files#diff-5ce72bac836d0ca6fa8f3082f38d28d2L170-L172

[dvc94ch]

I can't find the comment, I think the commit you linked is outdated? Github does some weird caching sometimes.

[goddessfreya]

https://github.com/dvc94ch/glutin/blob/glutin0.23-android/src/api/egl.rs#L178-L180

[dvc94ch]

NOTE to self

[dvc94ch]

NOTE to self

[goddessfreya]

Can glutin's readme be amended with instructions for building the examples on android?

[dvc94ch]

Closing due to inactivity