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

Behdad Esfahbod behdad at behdad.org
Tue Nov 30 08:29:41 PST 2010


On 11/30/10 11:16, Kristian Høgsberg wrote:

> 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.

Agreed.  Maybe we should do this for all backends (xlib, xcb, directfb, ...).
 That would *fix* the problem that currently any program linking to libcairo
will link in all the enabled backends at runtime.

In the past I've been opposed to this mode of operation, but I'm more positive
now, and it's probably what I will do in harfbuzz.


> 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) }

In fact, that table can be autogenerated using some preprocessor fun.

Cheers,
b

> 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


More information about the cairo mailing list