Re: [Libvisual-devel] GL library linkage

[Vitaly V. B. <vit...@us...>]

On Mon, 11 Oct 2004 15:54:52 +0200
Burkhard Plaum <pl...@ip...> wrote:

> > I think Libvisual should not be linked to libGL. It's not right
> > to link with libGL anyway - it's a kinda driver and it is different
> > for different hardware (and different driver versions, for NVIdia).
> 
> If the system is set up corrently, you can exchange the OpenGL
> libraries without breaking binaries.
Yes, most of the time, yes...

> There are MANY OpenGL programs out there, which come dynamically
> linked with OpenGL and work after you upgraded to the NVidia
> drivers.
./atlantis: /usr/lib/libGL.so.1: no version information available (required by ./atlantis)

... ugly, but it still runs.

> > It would be Much better if, say, Libvisual can dynamicaly load libGL
> > library and import its functions naming them smth like: lvglBegin()
> > etc.
> 
> So the plugin authors have to change 100s of OpenGl calls?
> I wouldn't do that.
... by hand. ;)

> If there is any "standard" in the Graphics world, it's OpenGl.
> It's available on many more platforms than libvisual will propably
> be ported to. Also the API is extremely clean and stable.
> I don't think that there are any ABI issues with OpenGL.
Agree. there should no ABI issues.

> It's a matter of taste, if you link the core lib with OpenGL or some
> driver. But plugins must assume that OpenGL is linked somehow (not
> just dlopenend).

One major benefit we'll get if we'll dlopen GL library is the ability
to use different hardware at the same time. Suppose there are
ATI, NVidia, S3Trio3D ;) hardware in the system, someone want to use it's
3D acceleration abilities and 3 monitors. Just because.

To do this gl calls should be "objectised". Like this
lvglBegin(video, GL_LINES);
 ...
lvglEnd(video);

to call specific function. If it's done nicely it should introduce almost
no overhead.

In theory ;) I can't see any problems with that.

-- 
Vitaly
GPG Key ID: F95A23B9