Use raw-window-handle

[DJMcNab]

Closes #256

This depends on rust-windowing/raw-window-handle#52, which means that we need a release containing it (rust-windowing/raw-window-handle#58). That however is going to be a churny release, because rust-windowing/raw-window-handle#55 is massively breaking.

@msiglreith what you have said in rust-windowing/raw-window-handle#54 suggests that this approach is not suitable for android, if I'm understanding that correctly? Would we need to update the TrustedWindowHandle every frame on android?

[msiglreith]

Here is a minimal example for wgpu on android I did some time ago: msiglreith/wgpu-rs@991c081

winit in particular only gives you a valid native window handle, therefore, raw window handle inbetween resume and suspend cycles. For different cycles the window handle may change so it needs to be handled appropriately. This means before running the event loop there will also be no handle available, resulting in a crash currently.

[DJMcNab]

I want to test this pr and compare it to master on android, to see if this introduces breakage. To be clear, it would surprise me massively if it did. My current understanding is that both should fail (crash?) if the application gets suspended and resumed.

@enfipy I don't have an android sdk installed, so if you could check this in the next couple of days that would be fantastic, but if not I might get around to it at some point

[DJMcNab]

This was a drive by automatic formatting, although I think this is nicer anyway

[DJMcNab]

This is still a draft since it depends on unreleased features of raw-window-handle

This is not high priority, but if anyone needs this functionality (@aclysma ?) urgently, we can recreate the internal api of TrustedWindowHandle in bevy. I'd prefer to wait for it to land upstream though.

[blaind]

I also worked on the android activity lifecycle problem before noticing this ticket. Got a functional PoC-solution. This would require upstream commit to winit, though.

Please check out:

• Explanation of the problem: Android Support #86 (comment)
• Bevy-patch: master...blaind:master
• Winit-patch: rust-windowing/winit@master...blaind:master

[DJMcNab]

Your changes look like they wouldn't conflict with mine at all in that case, which is positive?

So basically, this change would still be an improvement, and so can be safely merged once the raw-window-handle upstream catches up?

[blaind]

Your changes look like they wouldn't conflict with mine at all in that case, which is positive?

So basically, this change would still be an improvement, and so can be safely merged once the raw-window-handle upstream catches up?

Allright, sounds good! I've opened a pull request #1293 to continue discussion/development of the lifecycle part.

[DJMcNab]

Cool, that makes sense.

[cart]

I'm on board for these changes when upstream winit is ready for us.

[DJMcNab]

I've also opened rust-windowing/raw-window-handle#66, which we hopefully be able to use.

[alice-i-cecile]

This appears to no longer be blocked, per the linked issues :) Removing the label; hopefully we can get this polished and merged finally.

[DJMcNab]

V0.4 still isn't released - see https://crates.io/crates/raw-window-handle/versions

[cart]

It is worth pointing out that the new renderer is already using raw window handles:
https://github.com/cart/bevy/blob/305ff4c06322b934c3b307c60b1a571af615cb85/crates/bevy_window/src/window.rs#L129

[DJMcNab]

It's a simple enough change, that it can be recreated if needed.