nil
nil
Hmm, using the Plugin type to automatically make the label does seem like a reasonable reason to have the extra layer of indirection over exporting a function. > This is...
> if we made PluginLabel generic, we'd need to make PluginState generic too, which would be nasty Why? Looking at it a bit more carefully, I have no idea why...
> That's from android's vulkan loader and should also return a nullptr. > > edit: https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/vulkan/libvulkan/api_gen.cpp#608 If its from android's vulkan loader, why is it prefixed with `RustStdoutStderr`? That doesn't...
While I don't know if _this_ is a breaking bug, there is at least one breaking bug in the stack somewhere as the downstream issue shows. It could be this...
Would you mind sharing the code so I can test it as well?
> But you can try running the ash-window example using `android-ndk-rs` and `cargo-apk` Doesn't work :disappointed: It doesn't even compile, instead throwing a linker error with the folloving note: ```...
Well, I changed the code, but it still doesn't work. Here's my modified version: ``` //! Demonstrate interop with beryllium/SDL windows. //! //! Sample creates a surface from a window...
It worked! Well, almost. There is still no output to the screen, and touching it gives an ANR. But, the reason for that is winit doesn't poll the android event...
> `ControlFlow::Poll` currently doesn't poll the events it seems compared to the others variants. > Nonetheless, I think we drifted a bit from the original issue -> input&event handling should...