Re: [Libvisual-devel] GL library linkage

[Burkhard P. <pl...@ip...>]

> This is worst case scenario. If you need to intermix different contexts,
> you group gl calls anyway, don't you?

I wouldn't intermix the calls, because it's nonsense.
But as I said, less advanced programmers get strange ideas,
when nobody watches them :-)

Each API, which uses context pointers suggests, that intermixing
is possible (the same way you can intermix fwrite calls with
different FILE handles).

So it would IMHO the best solution not to use contexts for each
GL call, forbid intermixing and call glxMakeCurrent only once
per frame/context. And every OpenGL programmer will be happy,
because it's the way plain OpenGL works.

> If there is malloc()'ed struct with dlsym()'ed function pointers,
> call is like this
> 
> 	mov <struct address>(,%index_reg,4), %eax
> 	call *%eax
> 
> or something alike.

And this would be the case, if you would wrap dlsym()ed gl* functions into
lvgl* calls?

>>If the usage of multiple OpenGL libs cannot be avoided:
>>Would it make sense to have them in separate processes? The LD_PRELOAD
>>environment variable can easily force a certain libGL.so to be used,
>>and OpenGL can be used as we learned it.
> 
> That's too drain bamaging, sorry :)

IMHO less brain damaging than renaming and wrapping 100s of OpenGL
functions.

> So, as I wrote above, there is almost no difference between staticaly
> shared linkage and dlopen()'ed libraries regarding to speed.
> Is it OK to load dynamically libGL?

There are now 3 options:

1. Link statically
2. Link dynamically
3. dlopen

Which of 1 and 2 are used, is beyond control of the libvisual developers.
Because it depends on which libs (.a or .so or both) the user has installed
when compiling. Normally, the linker will perfer .so until -static is used.

So the question is whether to link opengl (i.e. -lGL) or dlopen() it.
I strongly believe, that linking is easier, it's the standard way to use
libraries and causes little overhead (and the burdon of making this
work is transferred to the gcc/glibc/kernel developers).

Furthermore, if some new functions appear in a later OpenGL version,
plugin developers can play with them without waiting, until a new libvisual
version makes them available through dlsym().

-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102