[Bf-committers] OpenGL optimisation

[Richard Berry]

Thanks to Matt Ebb, I've got an example Blender file with a high polygon =
count (via subdivision) surfaces. This is where OpenGL display lists =
really prove themselves; some benchmarks:

Blender 2.33a:
	draw: 33170 ms
	draw+swap: 32550 ms
	displist: 1956 ms
customblender2:
	draw: 3754 ms
	draw+swap: 3560 ms
	displist: 2201 ms

I also did some more profiling to see where the new bottleneck is:

http://www.warwick.ac.uk/student/R.J.Berry/highpoly.png

I tracked down the call to glDrawPixels to the draw_icon_centered =
function. This is used to draw the "centre" of objects:



static void draw_icon_centered(float *pos, unsigned int *rect, int =
rectsize)=20
{
	float hsize=3D (float) rectsize/2.0;
	GLubyte dummy=3D 0;
=09
	glRasterPos3fv(pos);
=09
		/* use bitmap to shift rasterpos in pixels */
	glBitmap(0, 0, 0.0, 0.0, -hsize, -hsize, &dummy);
#if defined (__sun__) || defined ( __sun ) || defined (__sparc) || defined =
(__sparc__)
	glFinish();=20
#endif=09
	glDrawPixels(rectsize, rectsize, GL_RGBA, GL_UNSIGNED_BYTE, rect);
}



This is bad. In-between drawing 3D geometry as fast as possible there are =
calls to glRasterPos3fv, glBitmap and glDrawPixels, which interrupt the 3D =
pipeline with 2D commands.

Apart from the shadow that these object centres have, I think we could =
reproduce the exact same functionality by using GL_POINTS and turning the =
depth buffer off (making them look nicer with GL_POINT_SMOOTH). I did a =
brief experiment to replace draw_icon_centered with GL_POINTS and this =
resulted in a speedup of about 10-15%: not fantastic, but it starts to add =
up when there are a load of objects on screen.

A profile of this is at:

http://www.warwick.ac.uk/student/R.J.Berry/highpoly-nobitmaps.png

r i c k