[vtk-developers] vtk performance - issue 1 - OpenGL state

Mark Beall mbeall2 at simmetrix.com
Wed May 16 09:19:14 EDT 2001


Here's the first of the performance issues. I'm going to post
these seperately under different titles to try to avoid confusion
and really long posts.

This first issue has to do with unnecessary calls to set 
OpenGL state (please excuse me if this terminology is incorrect,
I'm not an OpenGL expert).

Looking at the start of the Render function for vtkOpenGLProperty:

void vtkOpenGLProperty::Render(vtkActor *vtkNotUsed(anActor),
                             vtkRenderer *vtkNotUsed(ren))
{
  int i;
  GLenum method;
  float Info[4];
  GLenum Face;
  float  color[4];

  // unbind any textures for starters
  glDisable(GL_TEXTURE_2D);

  // disable alpha testing (this may have been enabled
  // by another actor in OpenGLTexture)
  glDisable (GL_ALPHA_TEST);

  glDisable(GL_COLOR_MATERIAL);

  Face = GL_FRONT_AND_BACK;
  // turn on/off backface culling
  if ( ! this->BackfaceCulling && ! this->FrontfaceCulling)
    {
    glDisable (GL_CULL_FACE);
    }
  else if ( this->BackfaceCulling)
    {
    glCullFace (GL_BACK);
    glEnable (GL_CULL_FACE);
    }

 etc...

You'll see that there are a large number of calls glEnable and
glDisable since the property has no idea of what was previously
set.
Eliminating these calls in a case where we knew they weren't needed
gave a significant performance increase in some cases (again
your mileage will vary depending on platform etc.)

It seems that the best thing to do would be to have something keep
track of the state and only make the gl calls to change things
that need to be changed. The place that would seem to make the
most sense to do this would be within the renderer itself.
The proposed solution is to add the ability of the renderer to
keep track of this state and functions for the property (and anything
else that changes these states) to call to set them. Then the
renderer will only change them if they need to be changed.

There are a couple of ways to do this, one would be to have a
function for each possible thing that needs to be changed. This 
would involve a lot of virtual function calls (although these
wouldn't really need to be virtual if, within the conceptual
model of vtk it would always be safe to assume that if I'm
a vtkOpenGLProperty, my renderer is a vtkOpenGLRenderer).
The second would be to have a single (or maybe just a few)
call(s) that would set related states.

Note that if this is taken to one possible logical extreme,
there would be no OpenGL calls in vtkOpenGLProperty, just
generic calls to the renderer, then there wouldn't even
be the need to subclass vtkProperty for different renderers.
Of course in this case the renderer functions to set this would
have to be virtual.

mark




More information about the vtk-developers mailing list