Client extensions are always available, and are only listed in
eglQueryString(dpy=NULL). Without this we can't call anything from e.g.
EXT_platform_base.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Binding an API does not change the type of the current context. Even if
it did, EGL 1.5 treats EGL_OPENGL_API and EGL_OPENGLES_API as identical
for this purpose. If you want to know properties of the current
context, query it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Some X server not supporting any OpenGL feature, glXQueryExtensionsString
will return NULL and causes the function to fail.
Thanks to Emmanuel Stapf (manus@eiffel.com) for the original patch.
This was verified running an application on macOS while the X server was
running on Windows Xming 7.5.0.10
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
...so that the generated code are buildable by pre-2013 Visual Studio.
The main thing that this does is that we avoid named initializers, but
instead initialize the structs in old-school C89 way.
The generated code may not look that robust, but since this is generated
code, I think this is not that much an issue; when the Khronos registry gets
updated, all that is needed is that the code gets re-generated, and we have the
items in the right order.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Most of the changes that happened after commit 8bbc0d40 broke epoxy
pretty much irreparably because of the CMake build and the attempt at
making libepoxy a static library that can be copy-pasted into another
project without generating files.
Since all the commits are entangled, and are full of unrelated changes,
we cannot simply do a localized set of reverts; instead, we need to hit
the reset button.
From this point forward, we're going to improve libepoxy's build while
attempting to keep the existing build system working. This may mean
reinstating the CMake build system at a later date.
Binding an API does not change the type of the current context. Even if
it did, EGL 1.5 treats EGL_OPENGL_API and EGL_OPENGLES_API as identical
for this purpose. If you want to know properties of the current
context, query it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
will return NULL and causes the function to fail. Thanx to Emmanuel Stapf (manus@eiffel.com) for the original patch.
This was verified running an application on macOS while the X server was running
on Windows Xming 7.5.0.10
...so that the generated code are buildable by pre-2013 Visual Studio.
The main thing that this does is that we avoid named initializers, but
instead initialize the structs in old-school C89 way.
The generated code may not look that robust, but since this is generated
code, I think this is not that much an issue; when the Khronos registry gets
updated, all that is needed is that the code gets re-generated, and we have the
items in the right order.
Since our provider enums are small, we can store them as bytes or
shorts if we just let the compiler know that it's OK. Saves 20kb in
the compiled library.
According to the OpenGL ES standard, "glGetString(GL_VERSION)" should
return a string starting with "OpenGL ES". However, PowerVR's OpenGL
ES implementation (and perhaps others) don't comply with the standard
here. If our context happend to be bound using EGL, then we can just
ask EGL what kind of context it was, avoiding the glGetString() check.
Don't mark epoxy_conservative_gl_version() for export, as it is meant
to be a private API to be used within libepoxy only.
Reviewed-by: Eric Anholt <eric@anholt.net>
This updates the script to generate code that is buildable by Visual Studio
2013 by:
-Using a macro to define the compiler-specific way to do noinline for a
function, and use it when needed.
-Avoid using empty arrays and structs as that is a C99 feature that will
likely be never support on Visual Studio as it is now an optional feature
of C11.
Without this, we got code generation that was dependent on the
original ordering in the hash table, and thus non-reproducible builds.
Based on a commit by Stephan Kulow, but retaining the sorting by
function name first (that way all providers with the same name appear
next to each other like before, and also happens to ensure that core
names tend to appear before non-core names)
This has been tested with both OpenGL and OpenGL ES on Android.
We can't use dlsym on Android to get all the function pointers since Android's libGLES* libraries are just shim libraries that pass everything through
to the real vendor specific libraries.
Due to this we must grab function pointers entirely through eglGetProcAddress instead of dlsym.
Fixes failure of the X Server with glamor using desktop GL on EGL, and
the associated testcase in the tree. This was clearly just
copy-and-paste failure on my part in
b251e3ae33.