Get this working everywhere

[Osspial]

The goal of this crate is to have a quick-and-dirty way to throw pixels into a buffer and display them on a window without a significant number of dependencies. Potentially, we'll be able to use this in the Winit examples to clear the screen quickly and get windows showing up with Wayland, but that would require that this work on all the platforms Winit supports.

@vbogaevsky @murarth @vberger @ryanisaacg @mtak- @goddessfreya - would any of you be able to throw together an implementation for the platform you've worked on in Winit? It's totally fine if you're unable or uninterested in working on this, and I have no desire to thrust work onto any of you that you don't want to do. However, you're the people I know I can ping, which seems like a good place to start for getting movement on this crate.

Anyhow, assorted implementation details:

• I have no idea if the current public API will work on all platforms. There's a good chance it won't, but figuring that out will be part of the design process.
• This crate doesn't depend on Winit directly - instead, it depends on raw-window-handle. That works fine on Windows, but there may be some friction on other platforms - particularly X11, which uses a #[doc(hidden)] API to load up Winit's X11 bindings. We should be able to resolve that problem by moving the X11-bindings-loading code into a separate crate that creates a lazy_static bindings object, which both Winit and winit-blit can depend upon.
  • That X11 work will be necessary for decoupling Glutin from Winit, which we should do in the long term. Getting this crate working should help lay the groundwork for figuring out how to do that.
• Ideally, this shouldn't be too complex to implement for the various platforms - the Windows implementation is about 250 lines, and the majority of that code is API boilerplate that can be copied to other platforms.

Let me know if there are any questions. Thanks!

[ryanisaacg]

I should be able to get this running on web without too much pain, but it might be a bit of time before I'm available to.

[elinorbgr]

Should be reasonably simple to implement for wayland too.

It only raises the question of double buffering. Generally wayland clients are expected to do it to avoid having the client modify the buffer while the server is still reading it (which could cause graphical glitches).

Not sure when I'll have the time to do it, but I'd be happy to mentor anyone willing to try it.

[Osspial]

@vberger good to hear! The current API implementation is already double-buffered, so implementing that on Wayland shouldn't be too much of a problem.

[Osspial]

A note that I forgot to mention in the main post: at some point I'd like to pull Winit's Size and Position types out into a separate crate so this crate and Winit master can use the same types, without this crate directly depending on Winit. We should aim to do that once the dpi overhaul has landed on master.

[goddessfreya]

I imagine most people will have already noticed this, but, I just wanted to mention I'm currently working on decoupling glutin from winit via three new crates (that are still heavily WIP and unpublished): winit_types, glutin_interface and glutin_x11_sym.

The purpose of glutin_x11_sym is to provide a single crate that downstream crates can all depend on for their X11 symbol loading. We also provide a single X11 display for downstream crates to all share, and some error handling code ripped out of winit.

winit_types simply rips out winit's error handling and dpi module and places them in a separate crate that both glutin and winit can depend on. This has the wonderful consequence of unifying glutin and winit's error types. I should note that while modifying winit's codebase to utilize this crate, I got confused by the ~4 different error types in use by the X11 backend, so I took it on me to cleanup the backend to just use Error everywhere.

glutin_interface serves a similar purpose to raw-window-handle, acting as an interoperability library for crates that wish to be compatible with glutin. Unfortunately, as it currently stands, raw-window-handle does not expose enough things to be usable by glutin. To enumerate all the reasons off the top of my head:

1. It does not expose the components necessary for making an EGL/GLX display.
2. Similarly, for WGL it does not expose a dummy HWND for finding the target pixel format with.
3. It doesn't expose an interface for pixmaps.
4. It does not expose an interface for allowing glutin to pass certain parameters to the window builders before the windows are built. More precisely, on X11 glutin needs to decide the XVisual and screen.
5. Similarly, on iOS glutin needs to decide, for some reason, the window's "root view class" (I'm not familiar with UIKit so don't ask me what this means) before the window is built.
6. It doesn't expose the size and hidpi factor of the windows, the later needed by glutin for its iOS backend while the former for its Wayland backend.

With that said, I'd like to hear everybody's feedback on the work done so far.

I'd also like to hear if @Drakulix is interested in implementing glutin_interface on gbm.rs, or if I should go ahead with the task myself. Doing so would allow glutin's EGL backend to be used with their crate.

[Lokathor]

Window properties that you want are up to you as a consumer of a raw window handle to find out on your own via the appropriate OS calls.

As to window creation, I doubt there's a way to make that unified in a good way.

[goddessfreya]

Window properties that you want are up to you as a consumer of a raw window handle to find out on your own via the appropriate OS calls.

On Wayland, as far as I and @Osspial could tell (as we were talking on discord), there appears no way to acquire the size that winit sets the window to via OS calls. Maybe @vberger is familiar way to do so? That would also allow us to automate calls to wegl::WlEglSurface::resize.

[Drakulix]

I'd also like to hear if @Drakulix is interested in implementing glutin_interface on gbm.rs, or if I should go ahead with the task myself. Doing so would allow glutin's EGL backend to be used with their crate.

I feel similar disappointment with raw-window-handle, as it is not really helping smithay's gbm use-case. (Although one could argue, that the gbm-interface is not really like any other window, but still...)

I would be glad to support viable alternatives in gbm.rs. I am currently a little busy, but I could likely work out support some time before the end of the year. If you could provide me with some hints, what needs to be done, that would be really helpful.

[elinorbgr]

On Wayland, as far as I and @Osspial could tell (as we were talking on discord), there appears no way to acquire the size that winit sets the window to via OS calls. Maybe @vberger is familiar way to do so? That would also allow us to automate calls to wegl::WlEglSurface::resize.

Now that you mention it, it is indeed not possible to retrieve this information for only the two pointers *mut wl_display and *mut wl_surface. This is basically why WlEglSurface::resize exists: the OpenGL stack cannot retrieve the size from these pointers, as the size of the surface is defined by what is drawn on it. So it needs to know what size the application wants.

[Osspial]

2. Similarly, for WGL it does not expose a dummy HWND for finding the target pixel format with.

Why is it necessary for raw-window-handle to expose that? It should be easy enough for Glutin to create its own dummy window for that purpose - it's already calling Windows API functions, so creating and destroying a temporary window doesn't seem like too much of a stretch. On a similar note, I don't think it's unreasonable to ask Glutin to call the native iOS size/DPI retrieval methods, although that still leaves the Wayland situation unresolved.

@vberger On Wayland, is it possible to attach functions to a surface after the surface's creation that intercepts events dispatched by the compositor (along the lines of the win32 subclassing API)? If that existed, we could have Glutin hook into Wayland's event queue to read the resize events directly, which would alleviate the context resizing problem.

[goddessfreya]

Why is it necessary for raw-window-handle to expose that? It should be easy enough for Glutin to create its own dummy window for that purpose - it's already calling Windows API functions, so creating and destroying a temporary window doesn't seem like too much of a stretch.

Fair enough.

On a similar note, I don't think it's unreasonable to ask Glutin to call the native iOS size/DPI retrieval methods, although that still leaves the Wayland situation unresolved.

Honestly, I didn't look into this one too much. My reasoning being that if Wayland's going to require size, then we might as well have all the platforms provide it.

[elinorbgr]

@vberger On Wayland, is it possible to attach functions to a surface after the surface's creation that intercepts events dispatched by the compositor (along the lines of the win32 subclassing API)? If that existed, we could have Glutin hook into Wayland's event queue to read the resize events directly, which would alleviate the context resizing problem.

Well, no, this is really not how Wayland is structured. How it works is that the server sends events suggesting a size, but these events do not go through the wl_surface, winit collects them through an other object (the wayland protocol splits things between a lot of objects). And in the end, it is winit that decides the new size of the window, and should forward this information to the part of the program in charge of drawing the contents.