[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