[Bf-committers] OpenGL optimisation

Richard Berry bf-committers@blender.org
Mon, 24 May 2004 20:16:37 +0100

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
	draw: 3754 ms
	draw+swap: 3560 ms
	displist: 2201 ms

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


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 =
	float hsize=3D (float) rectsize/2.0;
	GLubyte dummy=3D 0;
		/* 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 =
	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:


r i c k