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

[Kristian Høgsberg]

On Thu, Dec 2, 2010 at 4:02 AM, Benjamin Otte <otte at redhat.com> wrote:
> On Tue, 2010-11-30 at 11:29 -0500, 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.
>>
> Yes, We are so much better at writing a linker than the guys working on
> ld. And it worked so well for X.

Let's not be overly dramatic here.  We're obviously not writing a new
linker like X did (or maybe you just what X actually did), we're using
the existing infrastructure.  dlopen() of the desired gl library at
runtime is entirely feasible, considering that 1) dlopen of just the
libray name uses the same lookup mechanisms as link time resolution,
2) many of the entry points are extenions functions that we need to
look up anyway, 3) calling through a function pointers is actually
faster than the ELF GOT mechanisms and 4) the inherent brokeness in
this situation comes from Khronos and is outside our control, so we
can only work around it.

If we can drop the hyperbole, I'd be interested in any real arguments
against this you may have.

Kristian