stride
stride copied to clipboard
stride3d
Switch from OpenTK to custom bindings or future OpenTK 4.0
Just like MonoGame OpenGL.cs and Veldrid OpenGLNative.cs (#59), we might want to switch to our own "single-file" custom bindings for OpenGL.
Reasons:
- OpenTK is quite heavy and slow to AOT/compile on mobile (5mb because it embeds thousands of calls including all versions of OpenGL).
- We just care about a small subset of OpenGL
- Not much maintenance is to be expected so there won't be any of the much needed improvements.
- Lot of extra stuff in it we don't need (we simply need OpenGL unsafe callbacks as is)
- I contributed Android/iOS support so that we didn't rely on Xamarin's OpenTK, but ideally windowing/setup code should better be on our side for easier iteration.
- Bunch of bugs or things to workaround due to the way it's designed (I remember lot of issues/hacks with GL contexts switching on some platforms)
- Easy to add extension or custom enum values
Note: this is definitely not high priority but wanted to write it down for later or if somebody wanted to take care of this one.
The OpenTK team are actually currently working on refactoring the code to make it more modular so you won't need to take stuff you don't need. Pinging @Nihlus in case he wants to explain more about the work being done.
OK good to know. I remember this refactor was being talked about 2/3 years ago. Happy to learn it's under way!
Yes, we're currently in the work to modularize and modernize OpenTK. Adressing each one of the points in the issue, here's our current plans:
1, 2 and 3. It is our intention to make the library modular enough that if you want to target, say, OpenGL 4.6 and ES3.1, you can install those bindings and those bindings only. Furthermore, if you don't need windowing/input/etc, you simply just don't install those packages.
-
Within each profile, there'll be two packages - one with the raw bindings with no frills and whistles, and then one slightly higher-level one with OpenTK-specific additions (such as signatures taking vectors or matrices)
-
We're currently talking about the best way to handle Xamarin support. Since Xamarin source-bundled OpenTK 1.1 and enforces its use, our hands are sort of tied unless users do some rather nasty in-source aliasing workarounds. Any input or help in this area would be appreciated.
-
Open issues and contribute back! We are taking the time to do a quality pass in this refactoring as well, and one of the major things we lack is good information. Having an ongoing dialogue with Xenko - being a major game engine - and actively providing feedback on issues both ways would be extremely valuable.
-
I'd love to see some examples here - if it's something that should be provided through OpenTK, we'd gladly have it in the library.
You can join our Discord if you want some live chatting on the topic :)
@Nihlus Thanks for the summary, happy about the direction it's heading! Sorry for assuming wrongly, last time I checked the project was quite a while ago.
If the project is alive and well, I would be happy to give the new version a try and contribute if it fits our needs.
For 5 it might sound extreme, but maybe (slightly) renaming the assembly would avoid those issues (might be a good timing with all the API changes going on)? Of course, in our case we don't mind much the aliasing because we can hide it from our users, but maybe end-users might see it differently.
Keep up the good work!
@xen2 OpenTK has been showing its age recently, and it is in dire need of updating. Hopefully, we'll be able to provide a product that fits both old and new user's needs.
Re: 5 - Yeah, renaming the namespace and assembly has been on the table. I think it might be our only option unless Xamarin helps out.
The current working branch - 4.0 - is not currently in a usable state. We're in a period of sweeping API & tooling changes (working on the binding generator right now, myself), and we are not up and running in terms of feature parity yet.
OK, we should check back in a couple of months maybe, to see how OpenTK 4.0 is evolving. We're not in a hurry so fine with that.
Thinking aloud: is is possible Vulkan could eventually replace all use-cases for the OpenGL backend and thus sidestep the issue and reduce the number of backends (as well as effectively netting us a Metal backend as well as a happy side-effect)?
I could imagine a Vulkan-only backend (for Linux/next gen Android) and then leverage https://github.com/KhronosGroup/MoltenVK for the Vulkan->Metal mapping to handle MacOS/IOs. Granted this is assuming we care only about next-gen Android devices but given how quickly that market refreshes that might be reasonable?
Thanks for that. Note Xenko today uses SharpVulkan (a pretty 'light' dep at ~100K). Perhaps there would be some other advantageous with OpenTK/Vulkan however... I am not familiar with OpenTK.
Just wondering on my side if people see a future in which the OpenGL backend becomes redundant (in light of the existing Vulkan backend plus -say- MoltenVK). Or if that is a pipe-dream given the platforms Xenko wants to target or other considerations.
@jmkinzer I really wish I could get rid of OpenGL right now too, but if we decide to still support most of Android market, it will take quite some time to be mostly Vulkan = Android 7.0+ (right now it's 44%). Still, maybe we could decide to stop supporting OpenGL as early as possible once it reaches a certain threshold like 60% without waiting for 80%+? For sure it would save us some precious dev/maintenance resources!
(even OpenGL ES 2.x (up to Android 4.2) is still 23%! But we'll get rid of that soon, I suppose most of this market segment is not gaming)
Makes sense - I have absolutely no sense of where the android market is at so good to get some context. (And yeah - saving precious dev time was precisely my motivation).
