Find some way to support pure-Rust Wayland and X handles

[ids1024]

Both wayland-rs and x11rb have pure-Rust backends that don't require C libraries for X or Wayland. But to use raw-window-handle it's necessary to use xcb/xlib/libwayland to have a pointer to put in the display and window handle.

Are there any good ways to support this? It could be supported with feature flags that pull in x11rb and wayland-rs as dependencies, but that is a bit problematic in terms of API stability.

This would generally be limited to software rendering (such as with softbuffer) since the EGL and Vulkan WSI implementations are written in C and use these C libraries. So its usefulness would be limited, but it would be nice to have.

[notgull]

I originally suggested something like this in #94, although its usefulness would be limited since it can't really be used in hardware acceleration... although maybe it could be used in softbuffer?

The question then becomes "how do we get the RustConnection to fit into a RawDisplayHandle?" The only answer I can come up with that doesn't involve raw-window-handle taking on extra dependencies would be to have the variant contain an *const dyn Any that can explicitly be downcasted to an *const RustConnection. The disadvantage of this would be that, if the program uses multiple versions of x11rb, that there could be a version mismatch between the windowing system and the rendering framework, which would cause confusing bugs.

The way I would prefer, from a softbuffer standpoint, would be to just have another constructor on the Context type that takes an x11rb::RequestConnection to circumvent this entire issue.

[notgull]

Between this and #102, it makes me wonder if there is a niche in the ecosystem for a more opinionated window handle type. Maybe an enum between the "raw" window handle defined in this crate (maybe even the WindowHandle type to make it safer) and other more well-defined types?

[notgull]

My current stance is that this library should only expose the C window handles accepted by OpenGL and Vulkan. Other handles should be passed through other methods. Closing for now.

[madsmtm]

Somewhat related: In #134 we're doing exactly this, exposing a pure Rust handle, without a stable ABI.

So we could probably adapt the same solution to this.

[notgull]

I would argue that #134 is an extenuating circumstance, since there are no other good ways to pass your canvas object to the underlying graphics APIs. Even the data attribute hack can only accommodate types currently registered in the DOM. So our hand is forced into exposing wasm-bindgen, even in an unstable way.

My stance on pure Rust desktop handles is the same as above. The expense of keeping pointers to them is greater than the possible benefits of letting softbuffer draw to them. Unless Mesa allows for x11rb or wayland-rs handles to be passed to EGL, it's probably a bad idea to include them.

[madsmtm]

#134 is an extenuating circumstance

Yeah I probably exaggerated above, but I do think they share similarities, and that the solution we choose for wasm-bindgen could be adapted for x11rb/wayland-rs as well.

our hand is forced into exposing wasm-bindgen, even in an unstable way.

Well, we're never forced, we could also take the choice you've done for this issue, and just... Not support web handles at all, until they get a stable ABI that we can use. But nobody wants that, and so we take another route ;)

[notgull]

The core issue is that raw-window-handle exists mostly as a layer between the graphics APIs (glutin, wgpu) and the windowing system (winit, SDL, glfw). Which in turn mostly deals with C pointers. Unless you happen to have a friend on the OpenGL ARB it's going to be difficult to pass a wayland-rs pure Rust implementation to glutin or wgpu. So the main use-case is really only softbuffer.

On the other hand, the graphics APIs as they are currently exposed to Rust take wasm_bindgen::JsValue or wrappers around JsValue. Hence the exposure of JsValue.

It might be nice to have some kind of other, broader crate with a more expansive window handle type, for crates that don't wrap around graphics APIs. But for a lot of existing crates that use raw-window-handle, like winit, do not want to have x11rb as a public dependency.

[madsmtm]

Makes sense. I'll leave this open anyhow until we figure out #134, but will probably close it after that.

[notgull]

As of rust-windowing/softbuffer#171 softbuffer can create a context and run without a C connection.

This issue was discussed in our weekly winit maintainer's meeting and it was decided that it's out of scope for raw-window-handle, especially since it's possible to work with just the window ID's. Closing this as not planned.