|EGL GrGLCreateNativeInterface failing because of eglGetProcAddress|
|Project Member Reported by firstname.lastname@example.org, Oct 29 2014||Back to list|
The EGL version of GrGLCreateNativeInterface is using eglGetProcAddress (via egl_get_gl_proc). This was failing in an EGL environment, according to the EGL spec (1.3): eglGetProcAddress may not be queried for core (non-extension) functions in EGL or client APIs . For functions that are queryable with eglGetProcAddress, implementations may choose to also export those functions statically from the ob- ject libraries implementing those functions. However, portable clients cannot rely on this behavior. However, Skia is trying to query all function pointers through eglGetProcAddress, however it seems it is only intended and working for extension functions, not for core functions. I remedied this for my case by falling back to dlsym(RTLD_DEFAULT), however this no longer makes it EGL-portable but now relies on a posix-like environment for dlsym().
Oct 29 2014,
It seems like this can only be solved in a platform specific way, or by pulling in a GL header and linking against a gl lib. Thus far we've avoided the latter because we sometimes want multiple types of GL in the same build (e.g. native GL and ANGLE in the windows build) and have had issues with accidentally linking in the wrong implementation gl* functions. The assemble interface stuff means that the platform specific code is pretty small - a wrapper around dlsym and/or the windowing system's GL GetProcAddress (eglGetProcAddress, wglGetProcAddress, ...). I'm not really sure what to do here, but open to any suggestions. Also, happy to collect platform specific implementations in the code base as long as they're testable in our automated build system.
Oct 29 2014,
Why not expose the callback so that the caller is responsible for supplying a function to resolve the function names? It means you don't just have GrGLCreateNativeInterface but maybe you have GrGLCreateNativeInterfaceWithFunctionLookerUpper() or whatever, but it solves the problem in a way without making much impact on Skia's build and multiple GL configurations. It just makes it the callers problem to resolve.
Oct 31 2014,
That's a really good idea
Dec 7 2015,
|► Sign in to add a comment|