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.
This fixes crashes on ARM's Mali drivers, where desktop GL isn't
supported, and epoxy didn't notice the error and tried to dlsym() on
libGL.so.1.
An alternative would have been to look at the response from
eglQueryAPI() first, but that would have meant that we still need to
BindAPI in the case that eglQueryAPI returns something like VG or CL,
and so we needed to handle these errors regardless.
Fixes#22
Epoxy dlsym()s directly into libEGL instead of using dlsym() on a NULL
handle, so we can't relying on ELF resolution like we do for dlopen().
Instead, just override epoxy's function pointers for the functions
epoxy will call in the process of getting one of these bootstrap
functions.
The only way these get used is when you choose to include epoxy/gl.h
but EGL/egl.h. I'm not sure that's something I want to actually
support, but piglit happened to do so, and this gets things working.
There's not as much support here as in real khrplatform.h, but then
there's no EGL for windows. And seriously, compilers support 64-bit
and float types, why would you even build this complexity?
One of the problems with krhplatform.h (besides it being a terrible
idea in the first place) is that it's not present on many systems at
all, including apple, win32, and linux before late 2009.
So, unless we introduce the first ./configure dependency to the core
library build, we really do need to define these standard types to
their standard values. But if we allow khrplatform.h inclusion as
well, we'll get long-vs-int redefinition warnings on 32-bit. So, we
have to completely replicate the header, which is a thing we've done
for everything else except for eglplatform.h.
A testcase will be used to make sure that our types don't drift from
the system khrplatform.h types, if it even exists.
Fixes#17
Eric Anholt
Fredrik Höglund
Matt Turner