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

[Bill Spitzak]

Behdad Esfahbod wrote:
> 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.

I would much rather see a "dispatch table" for Cairo itself. Wasn't a 
big patch submitted that did exactly this? If I understand what is being 
proposed, the cairo library will still contain all the code to translate 
between cairo and, say, xlib, but you will avoid loading xlib itself by 
using a dlload and your own dynamic symbol table. If the dispatch was in 
cairo itself, you would simply be unable to create a cairo_xlib surface 
unless the cairo_xlib library was linked. If you don't want xlib then 
you don't link that and you don't get xlib or the glue code.

As I see it the cairo_t would contain a pointer to the dispatch table 
(or virtual function table if you want to call it that). *all* Cairo 
calls that take a cairo_t as an argument would be inline expanded like this:

  cairo_foo(cairo_t* cr, x, y, z) ->
    cr->table[FOO_INDEX](cr, x, y, z)

I think the submitted patch added error checking around this, but I 
personally would rather it be done directly and require the backend to 
do the error checking as well (mostly because the backend will already 
have the if statements and could modify the dispatch table to handle the 
disable-while-there-is-an-error feature of Cairo.

A complete dispatch table would help a lot for cairo backends that do 
recordings of the cairo function calls.