[vtk-developers] extension wrangler

[Moreland, Kenneth]

> > 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.

Yeah, I guess that would work.

> >   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.

The system not finding its own OpenGL .so/.dll is pretty rare.  And when
it happens the message is usually fairly clear ("Library blabla.so/.dll
not found.").  My point is that we increase the risk of not finding the
OpenGL library.  Giving an application the potential for a better
warning is little compensation for the error occurring in the first
place.

> And most 
> OpenGL libraries are put in a standard location nowadays.

If you say so.  Less than a year ago we had a problem with the system
installed and hardware specific GL libraries being installed in
different locations.

> > 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?

The worst possible problem: the parts using two different GL libraries
would actually compile and run just fine.  However, because only one
library was initialized and has a valid context, calls to the others
simply crash deep inside the library.  I've seen it happens several
times trying to get the extensions to work right, and it's a real pain
to figure out where the real problem is.

> > 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.

Actually it would make problems with different gl.h headers far worse.
In order to make this work, a program would have to parse gl.h much like
the VTK build now parses glext.h.  Currently, this process makes a lot
of assumptions about the structure of the header file and its
prototypes.  Any deviation from this structure causes errors in the
parsing.  This only works now because we have a single glext.h that is
maintained by SGI to hold all current extensions.

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

We all agree that problems could arise if VTK has its own OpenGL linking
and some other user code links directly against OpenGL.  What about a
program that uses both VTK and another library using OpenGL?  There
would probably be no practical way to make the other library use VTK's
bindings.

-Ken