How to migrate from `0.29`?
alexheretic opened this issue · 6 comments
I'm taking a look a migrating my various gl examples, crates & my game to the latest version. However, looking at the example seems to be the only way to understand the changes and I'm struggling to see how I should migrate. Previously I would use a relatively small amount of declarative code to provide me with what I needed, a gl window I can draw into. The only other non-winit bit then was the swap_buffers call.
The new API now requires me to know about display-apis, tbh I don't particularly want to. Isn't there a "best" choice for each platform that the previous versions were using? The example also uses explicit non-trivial conditional compilation to choose the display api. Do you expect all glutin users to re-implement this conditional compilation? Doing that would be quite verbose, I'd also have to unpick the features used in the example since display-api features don't really make sense downstream. It seems like it would end up a lot more code, which would be undesirable particularly in glyph-brush examples etc.
I'm also unsure exactly how the old code made the decisions I now need to satisfy (without going through the 0.29 code). It seems quite tricky for me to migrate my game without introducing changes in behaviour on one or more of the platforms I support (linux, windows, mac). It would be very useful to have "before and after" code examples, e.g. old ContextBuilder usage is now...
Overall I'm not sure I agree that glutin should have changed into a lower level crate. It doesn't seem to be able to do the job it could do for me before. Perhaps it could have been a new glutin-core crate or something and glutin could keep working a bit more like it used to? But I guess the ship has sailed there. On the other hand perhaps I've read the changes incorrectly, or my usage is more niche than I thought. I'd appreciate advice on how I should (or if I shouldn't?) migrate.
The new API now requires me to know about display-apis, tbh I don't particularly want to. Isn't there a "best" choice for each platform that the previous versions were using? The example also uses explicit non-trivial conditional compilation to choose the display api. Do you expect all glutin users to re-implement this conditional compilation? Doing that would be quite verbose, I'd also have to unpick the features used in the example since display-api features don't really make sense downstream. It seems like it would end up a lot more code, which would be undesirable particularly in glyph-brush examples etc.
This issue is actually an artifact of how OpenGL platforms are fragmented. With old glutin you had this sort of internally and to make work around this you need. What could solve is a separate crate with winit integration.
Why is that? Because on X11 you create the window after picking pixel format(otherwise crash). On Windows you create window before picking pixel format(otherwise won't load OpenGL icd). Besides that with GLX you need to share Xlib error handler, otherwise everything automatically neither Send nor Sync. So you can clearly see that this issues are not trivial and you can't really worked around them. The way it worked before only because winit was tightly coupled.
The picking display api is critical for some programs, since the underlying platforms are not the same. Some features only available on one of them for example and you can't even unify that
since the difference comes directly from the drivers impls.
Do you expect all glutin users to re-implement this conditional compilation? Doing that would be quite verbose, I'd also have to unpick the features used in the example since display-api features don't really make sense downstream. It seems like it would end up a lot more code, which would be undesirable particularly in glyph-brush examples etc.
Given that most glutin users are using the winit having crate that adds a shim would help you here, I'd guess. It's indeed true that most users don't really care about the difference, but the current design was driven by real world needs.
Overall I'm not sure I agree that glutin should have changed into a lower level crate. It doesn't seem to be able to do the job it could do for me before.
It was impossible to write certain code safely, some code was straight broken(EGLSurface was sent over threads on Wayland), android was a nightmare(You have window destroy, but you need it back), no ability to use in smithay or something like that, no ability to use with sctk and crates other than winit, not thread safe, the error handling is tight to winit. What you want is winit-glutin integration crate to take care for stuff like that. I'm fine with writing something like that, sure, but the initial goal was to solve issues with glutin blocking downstream from using multiple threads.
But speaking aside I can have a winit + glutin integration crate that could solve your problems, since all that difference will be hidden from you and you'll have less platform specific code.
Yes it's unfortunate right now that you have to write more code to deal with stuff you really shouldn't be dealing with and requires some knowledge.
I'll write some crate (which will be just a sinlge lib.rs file) and we will see how it goes.
The porting is indeed something that could be non-trivial if you never worked with OpenGL bootstrapping. And it would be nice to have it written down somewhere.
In the mean time you can look at alacritty/alacritty#6390 for a porting example.
Thanks. Yeah if there was a new winit+gl crate that did what old glutin did, that would work well for me i think.
The glutin-winit split is a good design decision in my opinion but it shouldn't have been a release yet by any means
The glutin-winit split is a good design decision in my opinion but it shouldn't have been a release yet by any means
I don't understand what mean by that. What released? A 100 LoC shim crate serving bootstrap boilerplate? This is not productive, sorry.
I developed my opinion at #1524