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.
Ensure that we also have import/export decorations for the prototypes, as
Visual Studio does not like such decorations on the function definitions
without the prototypes decorated as well, when the function prototypes
exist.
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)
These LDFLAGS go to the compiler, and getting the arg to the linker
requires -Wl or -Xlinker. gcc apparently was passing this through
anyway, while clang was getting angry.
This isn't quite as good as I'd like -- the XVFB setup doesn't support
a bunch of context creation extensions that we use, and I haven't
looked into the multiplatform stuff for doing OS X testing yet. I
think it's a good start, though.
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.
This increases the size of the library, but avoids some of the
concerns that have been brought up with the library silently switching
you from glWhateverEXT() to glWhatever() if there might be slight
behavior differences between the two that hadn't been identified. The
downside is that it means we can't share the resolver functions among aliases.
Now that it's split out from epoxy_get_core_proc_address(),
the particular symbols we were testing for before calling
GetCurrentContext() didn't make much sense, plus we were leaking
dlerror()s still.
I couldn't find a spec for this one on the internet, but this matches
the prototype in eglmesaext.h. The note in swap_region2 says:
4) How is this extension an improvement over EGL_NOK_swap_region?
RESOLVED: This extension builds on the previous
EGL_NOK_swap_region extension by requiring that the implementation
considers the update region provided by the application as a
mandate rather than a hint. This allows for region-restricted
rendering without requiring the use of preserved buffer swaps
which may be relatively expensive for the implementation.
Furthermore, whilst preserved swap behaviour is necessary for
incremental rendering, many applications fully re-render modified
surface regions and so don't require preserved swap
behaviour. This extension provides a lighter weight surface update
mechanism for such applications.
Eric Anholt
Chun-wei Fan
Dave Airlie
Christopher Meng
Ryan Houdek