[vtk-developers] extension wrangler

[David C. Thompson]

> That's an interesting idea, but I don't think I want to implement it. 
> I can think of several potential problems.
>  
> 1. It forces you to use a shared object / dynamic library for OpenGL. 
> That might not always be desirable or possible.
I don't think it would force dynamic loading. The function pointers
(i.e., vtkgl::Vertex3dv) could be statically assigned at compile time if
dynamic loading or a dynamic libGL wasn't available.

> 2. It complicates portability.  A lot.  We basically have to ensure
> that we duplicate the method for finding and linking to the OpenGL
> library.
I agree that this would be some work, although vtkDynamicLoader provides
a good deal of this already.

>   I have a feeling we would get a lot of users complaining about VTK
> not finding OpenGL.
Actually, I think dynamic loading would make this part easier, since a
failure by vtkDynamicLoader could be caught and acted upon (i.e., a
dialog box so the user could identify a valid OpenGL library). Without
runtime loading, people without OpenGL libraries click on an application
and either nothing happens or the dynamic linker kills the program
before it can display a sensible error message. And most OpenGL
libraries are put in a standard location nowadays.

> 3. It "ickifies" any OpenGL code.  Every single OpenGL call would need
> to be changed to use a loaded function.  Not a super hard problem, but
> if we miss anything or any developer in the future forgets, everything
> is going to break in weird ways.
I don't think things would break in weird ways... if someone was
developing using a static OpenGL, they might forget to use the "icky"
vtkgl::Begin instead of glBegin, but that would just cause link errors
for people with dynamic GL libraries (since their GL would not be linked
to vtkRendering anymore). What weird thing are you thinking of?

> Furthermore, all code using VTK would have to be changed to conform
> similarly.
Yes, I agree that would be a pain and is probably enough work to keep it
from happening. But it would also alleviate problems where vendors
distribute gl.h headers with different types (GLuint vs int and so
forth) in their function prototypes.

> That may not even be possible for some applications.
How so?

	David