Implementation tracking and API discussions for v0.24

[goddessfreya]

This issue tracks the implementation of my proposed Glutin 0.23 API as well as any discussion wrt
the API. PRs implementing these changes should be made against the v0.23_reworks branch. Changes to winit should be made against the winit-glutin-next branch.

To test the changes locally, the following repositories must be

git clone git@github.com:rust-windowing/glutin.git --branch v0.23_reworks
git clone git@github.com:rust-windowing/glutin_interface.git
git clone git@github.com:rust-windowing/glutin_x11_sym.git
git clone git@github.com:rust-windowing/winit_types.git
git clone git@github.com:rust-windowing/glutin_sys.git
git clone git@github.com:goddessfreya/winit.git --branch winit-glutin-next
git clone git@github.com:goddessfreya/gbm.rs.git --branch  glutin-fun

Changelog summary: https://github.com/rust-windowing/glutin/blob/v0.23_reworks/CHANGELOG.md
Proposed API: https://gentz.rocks/files/1580623488/target/doc/glutin/index.html

Implemented for:

• X11 - EGL ([Squashed] 0.23 Api Changes #1239)
• X11 - GLX ([Squashed] 0.23 Api Changes #1239)
• X11 - GLX/EGL Pixmaps ([Squashed] 0.23 Api Changes #1239)
• Linux - EGLMesaSurfaceless ([Squashed] 0.23 Api Changes #1239)
• Linux - EGLExtDevice ([Squashed] 0.23 Api Changes #1239)
• Linux - GBM ([Squashed] 0.23 Api Changes #1239)
• Wayland - EGL ([Squashed] 0.23 Api Changes #1239)
• OSMesa ([Squashed] 0.23 Api Changes #1239)
• Windows - EGL
• Windows - WGL
• Windows - WGL/EGL Pixmaps
• MacOS
• iOS
• Android (In progress: Glutin0.23 android #1274 )

Additional tasks:

• Get CI running for glutin_sys, winit_types, glutin_x11_sym, and glutin_interface.
• Publish version ones of those crates.
• On X11, if RANDR based scale factor is higher than 20 reset it to 1 winit#1403
• Implement glutin_interface on this crate. Smithay/gbm.rs#2

---

Originally intended to resolve #1140 and #1136, this set of changes has quickly spiraled into also covering #1243, #81, #501, and #466.

I wanted to have at least one implementation of the API before bugging people with it, and, well, now I got two of the major platforms down (Wayland and X11) as well as a handful of smaller targets on Linux.

Before progressing forward, I'd like to get some input on the API, as well as other people implementing the other platforms (I don't want to do them).

And now to CC anyone who I think might even be remotely interested: @aleksijuvani, @chrisduerr, @dvc94ch, @hatoo, @hecrj, @icefoxen, @katyo, @kchibisov, @Lokathor, @mb64, @mtak-, @murarth, @Osspial, @vberger, @vbogaevsky

[icefoxen]

Very intriguing, thank you! Thoughts, from a library user's perspective:

• ConfigsFinder could either be an incredibly handy little tool or a tarpit of trying to express every possible combination of desires, depending.
• I'm not too clear about how to actually apply this library right off the bat, but an example or two will probably solve that.
• I would be surprised if some of these functions/methods/objects are not unsafe and we should put some serious thought into making sure it's right.

Looks pretty nice all in all though!

[goddessfreya]

ConfigsFinder could either be an incredibly handy little tool or a tarpit of trying to express every possible combination of desires, depending.

Yes, this is very much a concern of mine. I figure worst case scenario, all users end up setting all the Option<...>s of ConfigsFinder to None (only two aren't None by default now, alpha and color bits) and sorting through them all themselves. Either way, I figure this is very much an improvement other having to make multiple Contexts and Windows as ends up happening in the older API.

I'm not too clear about how to actually apply this library right off the bat, but an example or two will probably solve that.

All the examples on the branch have been updated plus a couple demonstrating the new platforms. I plan to add small examples inline with the docs and make them less wordy over the following weeks (since, I must admit, they are pretty bad).

I would be surprised if some of these functions/methods/objects are not unsafe and we should put some serious thought into making sure it's right.

Agreed.

[icefoxen]

I haven't had coffee yet, but thinking a bit about the ConfigsFinder thing... Basically what I actually see in practice is usually two patterns. Either someone just says "Get me a graphics context with these properties I want, and fail if it doesn't work", which these days usually amounts to 32-bit RGBA, 24-or-whatever depth buffer, and a few other sane-ish defaults. OR, someone wants to put the work in to saying "Find something like config A, if you can't then fall back to something like config B, then fall back..." and so on. Seems like the easy design is to optimize for the happy path of the first case, where if you can't provide what someone wants then you just tell them so. Then if someone wants to go through multiple fallbacks they do it themselves, instead of relying on your heuristics to try to get them something "good". That way each extreme has at least a clear choice, then if we want there's space in between those extremes for a function that tries to guess a good config for you, and is capable of saying "Well you asked for 8x MSAA and I can only give you 2x MSAA but everything else you asked for is there".

Sorry if this is obvious, I'm just shuffling it around in my own head.