A bit of an open discussion here about an issue I’ve spotted. Input and criticism welcome.
This stems from the following two bugs, and how our handling of extra flags for GL context creation actually risked some pretty bad behaviour in terms of SDL2’s very cool forwards compatibility feature.
The key thing to note here is that the added enums in SDL_GLattr are not guaranteed to match up, say, if two patches are sent side by side with different additions, and those two developers build apps using their own patches. Ryan would have a hard time picking the favorite, and the other app would have unexpected behavior if it was ever used with newer SDL. (Perhaps it’s bad behavior to ship a patched SDL, but this sometimes can’t be avoided).
This will happen to our apps if asked to use the NV_robustness_video_memory_purge extension and run with a theoretical SDL in the future that has a new SDL_GLattr in its place. Luckily, this isn’t a significantly likely scenario - this extension is really never to be used in a production environment, and Maximilian Malek quite rightly points out it should have a very limited lifespan.
It does, however, highlight an issue that the abstraction layer causes - adding new GL context creation attributes that SDL doesn’t yet support can be a risky business, and we just got lucky this time.
A way to solve this would be to allow passing of platform-specific context creation values directly into SDL. But I’ve not delved too deep into the SDL2 abstraction layers before, and don’t know if passing platform-specific information directly would be against the SDL methodology enough to warrant that solution not being viable. Also maybe this isn’t a problem that needs a code solution anyway, just a post on an internet forum that’ll show up as a warning the next time someone searches for adding SDL_GLattr values or similar.
Anyway, thoughts appreciated. I figured getting this down on paper to fulfill at least the latter part of that last paragraph would be a good idea.