Dynamically load EGL and GLES extensions as is done for desktop GL#1603
Merged
Dynamically load EGL and GLES extensions as is done for desktop GL#1603
Conversation
…nd GLES extensions as is done for desktop GL.
eXpl0it3r
force-pushed
the
feature/gles_extensions
branch
from
e524216 to
6c75914
Compare
eXpl0it3r
approved these changes
Sep 1, 2019
Closed
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This makes it possible to build/run SFML applications on more (all?) systems that support EGL and GLES1. Previously, it would fail to build on Raspbian due to linker errors caused by missing entry points in the GLES1 library provided.
The idea behind OpenGL extensions is that applications can determine at run-time which extensions are support on the target platform and adjust their behaviour accordingly or in certain cases just terminate gracefully. In order to allow functions to optionally be available, the underlying library will have to be dynamically linked and the entry points loaded at runtime, if they are available.
It seems like standard practice that mobile applications are built for a certain target platform and are neither forward or backward compatible with other theoretically compatible platforms. This might seem normal for experienced mobile app developers, but it seems like a completely broken philosophy to me, especially because I come from a desktop world.
Because EGL and OpenGL ES were never meant to be used exclusively on mobile platforms, dynamically loading their entry points at runtime is the only reasonable path forward in order to support all platforms with a single implementation.
Currently, the choice between desktop OpenGL and OpenGL ES still has to be made at build configuration time, but maybe that can change in the future. I don't see any reason why they can't co-exist in a single library instance. Loading EGL and GLES entry points dynamically is the first step in this direction.
I replaced the glLoadGen loaders with loaders generated by glad, simply because glad is actually being maintained and generates stuff we can use. In order to avoid symbol conflicts with a user provided loader, the glad loader symbols have been manually prefixed with sf_ and SF_ and the loading functions all made static. This feature is likely to be built into future versions of glad.
Obviously, this change affects all platforms that SFML currently supports, and since I can only test on those I have at my disposal, it would be nice if people with access to other platforms could test to see if this change builds/runs on their system. It is not unlikely there will be crashes and weird behaviour all over the place, but that's why we test.
This would supersede #1577.