[Tracker] Better windowing/graphics inter-operation

Lokathor commented 5 years ago

Update: Most work is done! Unfortunately this didn't help the GL API as much as it helped the newstyle APIs like Vulkan/Metal/gfx-hal/wgpu, but it was a good improvement.

Windowing Side

[x] winit: raw-window-handle is supported as of 0.20.0-alpha3
[x] glutin: GL has problems in general with it, but glutin uses a new enough winit that it technically has the support.
[x] beryllium: Available in 0.1 series and via feature in 0.2 series
[ ] sdl2: Issue opened, https://github.com/Rust-SDL2/rust-sdl2/issues/910

Graphical Side

[x] ash: Ash doesn't track the extensions enabled, so it can't actually use raw-window-handle to automatically do anything for you. You're just on your own, which is what you'd expect from a minimal bindings library.
[x] gfx-hal added in https://github.com/gfx-rs/gfx/pull/3038
[x] wgpu: Fixed in https://github.com/gfx-rs/wgpu-rs/pull/70
[x] glow: Updated to a new enough glutin in https://github.com/grovesNL/glow/commit/7a73cf9a258ec326fd378cc4388ce1bb926a808e, though the GL limits still apply.

original issue post follows:

gfx-hal (technically the Instance type in gfx-backend-foo for one of gl, vulkan, dx12, etc) takes a &Window, but all types actually secretly have their version number as part of their type so it takes a &Window-v0.19.0. That's fine and all except there's a new 0.20.0-alpha2 out and people are supposed to be trying out that new alpha but they can't draw a picture because it's the wrong version so you get a type mismatch error. We can hardly alpha test the library if we can't even draw a picture. The backends have a plan for what to do: ignore their winit integration, possibly disable the winit feature entirely, and then use the create_surface_from_THING version for whatever raw window thing you have. This is annoying, but you can do it. The gfx-backend-vulkan crate has support for xlib, xcb, wayland, and even an existing vulkan surface. Honestly, all that create_surface does with the &Window is look inside the Window for the raw window data (using the right platform specific extension trait), and then call one of the other constructors anyway.

What we should do is cut out the whole middle step where gfx-hal has to know about the unstable winit crate, and we let it rely on a very stable interface that both winit and gfx-hal and other window libs and other graphical libs can all agree on.

We'll call the crate raw-window-handle (bikeshed here). The crate only needs a single trait and a support enum for the return value of the single method on that trait:

pub unsafe trait HasRawWindowHandle {
  fn raw_window_handle(&self) -> RawHandleData;
}

pub enum RawHandleData {
  Win32{ hwnd: *mut c_void},
  XLib{ display: *mut c_void, window: u64 },
  Cocoa{ .. } \
  // etc, one for each windowing system,
  // we prefer c_void and pointer casting instead of the "real" pointer
  // types when possible so that it builds easily on all platforms.
}

Then winit implements this for Window, and gfx-hal backends can write create_surface(win: &impl HasRawWindowHandle), and end users trying to get the two to talk to each other stop having to match their versions up quite so tightly. The raw-window-handle crate can just be one of those "0.1 crates that basically never updates because it does the job fine as is" like libc, perhaps to become 1.0 once we've really kicked the tires a bit., perhaps never to even bother with 1.0 at all.

And that's something we could get done in just 1 month.

Osspial commented 5 years ago

Oh welp, github had the comment saved. I thought I hadn't sent it :V

Lokathor commented 4 years ago

The last pending checkbox (sdl2) has an issue placed for this in their repo, so I'm going to close this one up as "Success".

rust-gamedev / wg