[VTK ARB] Rework the OpenGL extension mechanism

[Francois Bertel]

Hello,

I'd like to broad to the attention of the ARB that, as it is right
now, the OpenGL extension mechanism (including also the subclasses of
vtkOpenGLRenderWindow) in VTK has several flaws that I would like to
see addressed:

1. STRING COMPARISON vs BOOLEAN COMPARISON.

Right now, each component of VTK using extensions or OpenGL core
feature>1.1 need to first test if the OpenGL version is supported or
if the extension is supported by string comparison. It could be redone
by asking to parser to create
a list of boolean values instead to avoid this overhead.

2.  FUNCTION POINTER INITIALIZATION: PER VTK COMPONENT vs ONCE AT
CONTEXT CREATION

Each component of VTK using extensions has to initialize the related
functions pointers provided by an extension if any. If "N" components
uses the same OpenGL features, this operation will happen "N" times.
Instead this could be done once
for all the functions pointers during the OpenGL context creation. It
also make the code of the VTK components bigger than it should be.

3.  PARSER IS OBSOLETE

The OpenGL parser is obsolete regarding new syntax in glext.h
(OpenGL), wglext.h (Windows) and glxext.h (X11/GLX). Notably, wglext.h
introduced a struct that the parser cannot understand and the change
the parser is not trivial.

4. PARSER DOES TOO MUCH AND NOT ENOUGH

The same OpenGL parser is used to parse glext.h, wglext.h and
glxext.h. It translates too much. Not only is creates functions
pointers but also constants from macros. A macro like GL_TEXTURE_3D is
translated into vktgl::TEXTURE_3D.
 It does not have to be that way. It should just translate function
pointers. For the macros and data types glext.h wglext.h, wglext.h
could be included directly by VTK. By using macro GL_GLEXT_LEGACY and
GLX_GLXEXT_LEGACY we can
avoid conflict between glext.h provided by VTK and glext.h provided by
the system.

5. FUNCTIONS POINTERS ARE STATIC

The functions pointers are stored as static. Theoretically, functions
pointers are per OpenGL context. If an application uses 2 contexts we
currently rely on the fact that we will be fortunate enough so that
the function pointers match.
In most situations, this is usually not a problem. Sometimes it can
be. Notably if you use a hardware accelerated context in combination
with a software context. This is possible on Windows. This is possible
on Mac.

A solution would be the have a list of functions pointers per context,
that we can share between contexts that actually have the same
pointers. To detect if two contexts have the same list of pointers, we
can test a particular function pointer.
We could style use the static pointers, but they would be assigned
when there is a context switch. If there is a context switch but the
two contexts involved in the switch share the same pointers then we
can skip the assignment operation.

6. WINDOWS MECHANISM CAN NOT USE WGL EXTENSIONS

Regarding Windows, vtkWin32OpenGLRenderWindow creates a OpenGL context
and uses it directly. This is not the way it should be on Windows. On
Linux, the glx extensions are available before creating a context so
we can use glx extensions
in order to create the right context (for example a context using
multisampling). On windows, a current OpenGL context is required prior
to access wgl features. The solution is to first create a dummy
context, then use wgl features to create a more
elaborate context. For example, right now, we cannot create a context
on Windows using multisampling because of that. We cannot use pick a
specific GPU (extension WGL_NV_gpu_affinity) because of that, we
cannot create forward compatible OpenGL 3.x context because of that.
We cannot switch on/off synchronization with vertical blank because of
that.


Here is an example of something we cannot do right now (extension
WGL_NV_gpu_affinity), that would be helpful for some ParaView user :

http://www.paraview.org/pipermail/paraview/2010-May/017625.html


-- 
François Bertel, PhD  | Kitware Inc. Suite 204
1 (518) 371 3971 x113 | 28 Corporate Drive
                      | Clifton Park NY 12065, USA