Can't create display without platform-specific logic to define a `DisplayApiPreference`?
ids1024 opened this issue · 9 comments
Unless there's something I'm missing, in Glutin 0.30 it isn't possible to create a Display without providing a DisplayApiPreference, and it isn't possible to create one of those in a portable way without conditional compilation.
Is there any reason not to provide a DisplayApiPreference::platform_default() method, or something similar? Defined similarly to how it's handled in create_display in glutin_examples? That would provide any easy solution for library consumers looking for something that just works without worrying about the specific API used on a particular OS.
Well, I guess it needs to take a RawWindowHandle too.
Not sure how to deal with the XlibErrorHookRegistrar callback.
Unless there's something I'm missing, in Glutin 0.30 it isn't possible to create a Display without providing a DisplayApiPreference, and it isn't possible to create one of those in a portable way without conditional compilation
It's more of an Api burden, you can use EGL/CGL, they don't require anything special to build them.
Is there any reason not to provide a DisplayApiPreference::platform_default() method, or something similar?
Unfortunately no, we can't do that since it requires getting the data from winit or whatever you end up using. You can use EGL/CGL though since they are not asking for any of that, but be aware that you have to use them. This data is critical to functioning and can't be avoided. The glx part is the most complex and I'd suggest to look at how winit part is implemented. Yes it's really required to be that way with glx.
Not sure how to deal with the XlibErrorHookRegistrar callback.
That's an Xlib issue, I'd suggest to look at the example on how to obtain such.
We may have an option to write glutin-winit integration layer which will help with bootstrapping for example similarly how it was doing before. Such crate could be just a single file lib.rs.
Would you be interested in using such crate that does initial display/window bootstrapping for you?
It's more of an Api burden, you can use EGL/CGL, they don't require anything special to build them.
I guess EGL should work on any more-or-less modern Windows/Linux/BSD system? And there mostly shouldn't be any reason for a portable application to care whether it's using GLX/WGL or EGL, as long as it's not reliant on particular EGL extensions or anything specifically tied to GLX or WGL? I don't know if there are also subtleties regarding specific drivers.
The requirement to have a RawDisplayHandle for WGL isn't such a problem; the function could be something like fn platform_default(RawWindowHandle) -> Self. (Even if the RawWindowHandle is needed for most backends, it isn't really a problem in the common case of creating a context to render to a window.)
But yeah, the xlib error hook thing is tied to winit in a way that isn't just getting a RawDisplayHandle and RawWindowHandle.
We may have an option to write glutin-winit integration layer which will help with bootstrapping for example similarly how it was doing before. Such crate could be just a single file lib.rs.
Perhaps such a single file library could simplify some of the initial bootstrapping. Though if it were possible to provide a simpler API here it would be useful when used with or with winit. Or at least clearer documentation for what's recommended.
On the whole glutin 0.30 + winit isn't too much harder than glutin 0.29 (and it's great that it isn't specifically tied to winit anymore), even if there are a couple more steps to the initial bootstrapping. DisplayApiPreference is a one part that could at least be better documented. (If I'm not writing something platform specific, should I just copy the boilerplate from the example? If multiple are available, what reason do I have to "prefer" one?)
I guess the other complication that could at least have clearer documentation is finding a Config. If there's some sensible default that doesn't require the user to iterate over configs and test anything about them, there could be some kind of simple helper function.
But yeah, the xlib error hook thing is tied to winit in a way that isn't just getting a RawDisplayHandle and RawWindowHandle.
It's not tied to winit, you can write your own one just fine with x11-dl or something. It's not a big deal if you're familiar with x11 programming.
Perhaps such a single file library could simplify some of the initial bootstrapping. Though if it were possible to provide a simpler API here it would be useful when used with or with winit. Or at least clearer documentation for what's recommended.
Are you talking about display picking and api preference? Do you want to know what using this display would provide you over picking the other display? Like EGL over GLX/WGL? I could certainly add docs and caveats about using one over another.
The winit example could help with just winit though, but other windowing libraries are not really cross platform in rust and they can use api module directly where such thing as preference is not exposed.
On the whole glutin 0.30 + winit isn't too much harder than glutin 0.29 (and it's great that it isn't specifically tied to winit anymore), even if there are a couple more steps to the initial bootstrapping. DisplayApiPreference is a one part that could at least be better documented. (If I'm not writing something platform specific, should I just copy the boilerplate from the example? If multiple are available, what reason do I have to "prefer" one?)
The reason to prefer one over another is mostly due to missing features in some implementations, they are not equal under the hood.
I guess the other complication that could at least have clearer documentation is finding a Config. If there's some sensible default that doesn't require the user to iterate over configs and test anything about them, there could be some kind of simple helper function.
The config has a good default and this default is documented, but in a way that it says what is a default value for each field. See the ConfigTemplateBuilder docs, since that's the thing you configure and the thing.
If you have a way to make it more discoverable wrt configs PR is welcome.
Are you talking about display picking and api preference? Do you want to know what using this display would provide you over picking the other display? Like EGL over GLX/WGL? I could certainly add docs and caveats about using one over another.
Exactly. Users of the crate may not be very familiar with any of these APIs, and especially not all of them.
other windowing libraries are not really cross platform in rust
There's an SDL crate, but I guess that provides its own way to create an OpenGL context. So fair, there's nothing else I'm aware of that would be portable. It's neat that Glutin can now be used directly with wayland-rs/smithay-client-toolkit for instance, but then DisplayApiPreference is easy enough. Only EGL.
The config has a good default and this default is documented, but in a way that it says what is a default value for each field.
Yeah, the builder has defaults. But if glutin_examples/src/lib.rs is representative of expected use, it doesn't simply create the ConfigTemplate and use the first config it finds, but sets different template parameters on CGL, and and iterates over configs, including an X specific check.
So here too, if the example is representative, there's a bit of boilerplate involving details related to specific backends/platforms.
There's an SDL crate, but I guess that provides its own way to create an OpenGL context.
The SDL provides the entire windowing platform for you, the event loop and so on. You can't use SDL with e.g. smithay-client-toolkit or smithay for example, while glutin can be used with anything that can provide DisplayHandle.
Yeah, the builder has defaults. But if glutin_examples/src/lib.rs is representative of expected use, it doesn't simply create the ConfigTemplate and use the first config it finds, but sets different template parameters on CGL, and and iterates over configs, including an X specific check.
So here too, if the example is representative, there's a bit of boilerplate involving details related to specific backends/platforms.
I could add more docs about that sure. I was just trying to show how you can use the fact it's an iterator, and how you can pick higher multisampling for example, since by default it's zero, since not everyone needs it, but that's basically AA.
Added glutin-winit crate to help with winit bootstrapping.