[cairo] [cairo-gl] RFC: Dispatching mechanism for non-standard GL functions

[Kristian Høgsberg]

On Tue, Nov 30, 2010 at 8:24 AM, Alexandros Frantzis
<alexandros.frantzis at linaro.org> wrote:
> Hi all!
>
> In the process of removing GLEW, I have started to implement a
> dispatching mechanism in cairo-gl for the GL functions that may have
> different names in 1.x, 2.x and ES 2.0 (ARB/EXT etc).
>
> The idea is that each gl_context carries its own dispatch table which is
> filled by calling the appropriate *GetProcAddr function (and taking into
> account the version and available extensions) when the context is
> created. All calls to the contained functions should only be done
> through the dispatch table.
>
> The dispatch table is currently embedded in the gl_context struct and
> initialized on every creation. However, it may well be a global
> per-flavour (glx, egl etc) struct that is lazily initialized only once
> and just pointed to by or copied into the gl_context.
>
> The dispatch table approach minimizes the need to have separate code
> paths for core 2.0 vs 1.x ARB. For example, I have removed the shader
> backend implementation for ARB. Even when using 1.x ARB, the core 2.0
> shader path should work fine once the dispatch table has been correctly
> set up.
>
> I have attached an early WIP patch for initial review and feedback.
> Using the cairo test suite I have found no regressions for GL 2.0 (of
> course GL 1.x ARB doesn't work yet).

I think that looks very promising.  How many "regular" gl calls are
left?  It looks to me like it could be feasible to just lookup all gl
entry points.  That would let us dlopen libGL.so or libGLESv2.so at
runtime and lookup all entry points.  My only reservation about this
was that we need to know where libGL.so is, but reading the dlopen man
page that's not true.  If you just dlopen("libGL.so") it will look in
the same places as the dynamic linker, including LD_LIBRARY_PATH etc.
So I'm leaning towards that idea now to avoid making the choice
between GL or GLES2 a compile time decision.

As for the patch, I'd recommend making an array of entry point name
and the offset into the dispatch struct (using offsetof):

  { "glFramebufferTexture2D", offsetof(cairo_gl_dispatch_t,
glFramebufferTexture2D) }

Then you can just loop through the array and initialize the entry
points.  It generates a lot less code and it's easier to add error
checking.  As a nitpick comment, I'd just drop the "gl" prefix for the
function pointers in cairo_gl_dispatch_t - they don't need namespace
protection as struct fields.

Kristian