# OpenGL CallList slower than Begin/End...?

This topic is 4814 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello all, I've got a large dataset of lines that I'm rendering. I was getting about 47fps (via a Fraps check) on a Athlon-64 3000 & NVidia 6600 GT with sending the vertices via glBegin/glEnd every frame. Thinking that would most likely be the bottleneck, I compiled a display list and changed the render loop to simply glCallList. Much to my suprise, my frame rate _dropped_ to 37fps. After thinking about this a bit, I'm guessing that it's possible that vertices which are sent via Begin/End might be culled by the driver before sending them onto the hardware. Whereas with a display list, the driver doesn't do any culling and sends them on to the hardware directly. If I pull the camera all the way back so all of the lines are in view, then my frame rate drops to about 38fps, so this seems likely. Does anyone know if this is how NVidia's OpenGL driver works? I wouldn't expect the driver to do any culling for me at all -- but maybe NVidia does whatever they can to get extra performance... :)

##### Share on other sites
yeah nvidia does do culling in the drivers. theyve gotten alot of flak for it too.

post some code of how you are generating the lists

##### Share on other sites
make sure you aren't creating a display list per frame, or even several times a second. this is not an effecient use of display lists, but i still see people do it.

##### Share on other sites
Turn culling off, draw as a wireframe or with transparency or something like that.

Then compare performance.

This will give you a better idea of whether or not culling is responsible.

##### Share on other sites
Quote:
 post some code of how you are generating the lists

Code... well, it's not much...

Since this is work-related code, I've had to trim out a few things, but the GL calls are done pretty much in this order.

	// create line display list	linDList = glGenLists(1);	glNewList(linDList, GL_COMPILE);	glDisable(GL_DEPTH_TEST);	for (t = 0; t < linCount; t++)		_drawLIN(&linList[t]);		glEndList();--------------------------------------------------------------static void _drawLIN(LINData *lin){	// iterate through all entries	for (entryIdx = 0; entryIdx < lin->entryCount; entryIdx++)	{		glColor4ubv((u8 *)&colorTable[entry->color]);		// render a line strip		glBegin(GL_LINE_STRIP);		// send all points		while (pointCnt--)		{			// send it			glVertex2f((lin->xpos + point->x) * 15.0f, (lin->ypos + point->y) * 15.0f);		}		glEnd();	}}

The render code simply calls: glCallList(linDList). I don't think you'll find anything out of place, though. :)

Just to give you an idea of how much data I'm dealing with, the total number of lines is 71726 (289728 vertices). I guess I'll just have to implement my own view frustum culling earlier than I expected. *sigh*

Quote:
 make sure you aren't creating a display list per frame, or even several times a second.

I'm not. The load routine and the render loop are completely separated.

Quote:
 Turn culling off, draw as a wireframe or with transparency or something like that.

These are lines, not polygons. Just how do I turn culling off, or draw a line as wireframe? :)

##### Share on other sites
Quote:
 Original post by adam17yeah nvidia does do culling in the drivers. theyve gotten alot of flak for it too.
God forbid NVIDIA should optimize their drivers.

##### Share on other sites
Quote:
Original post by bpoint
...
I'm not. The load routine and the render loop are completely separated.

Quote:
 Turn culling off, draw as a wireframe or with transparency or something like that.

These are lines, not polygons. Just how do I turn culling off, or draw a line as wireframe? :)

that still sounds worrisome, diplay lists take extra overhead to create, so if your data changes often they can actually create a performance hit. if areas of the display are static, then put them in a display list. if your data rapidly changes, you should not be using display lists.

if your lines never change, you can always draw to a texture for extra performance as well.

EDIT: and don't cull lines, but the call is glEnable(GL_CULL_FACE).

##### Share on other sites
Just use vertex arrays and be done with it. Display lists are not the recommended batching method.

##### Share on other sites
Quote:
 Original post by anistthat still sounds worrisome, diplay lists take extra overhead to create, so if your data changes often they can actually create a performance hit. if areas of the display are static, then put them in a display list. if your data rapidly changes, you should not be using display lists.

The lines are static -- they never change.

Quote:
 if your lines never change, you can always draw to a texture for extra performance as well.

Unfortunately, that won't quite apply for what I'm doing. Regardless of the zoom level (camera position), I need a constant width for the lines. Plus, I'm nearing the limits of texture memory as it is already.

Quote:
 and don't cull lines, but the call is glEnable(GL_CULL_FACE).

Face culling is already enabled for other polygons/meshes in the scene. Disabling it didn't seem to affect speed either way though.

Quote:
 Just use vertex arrays and be done with it. Display lists are not the recommended batching method.

I was under the impression display lists would cut out a large portion of the Begin/End overhead (at least, that's the way it worked on the GameCube :) ), but if anything, it just helped cut back the function call overhead on the CPU.

I will try vertex arrays and VBOs later on. Thanks for the idea.

##### Share on other sites
Quote:
Original post by bpoint
The lines are static -- they never change.
Regardless of the zoom level (camera position), I need a constant width for the lines. Plus, I'm nearing the limits of texture memory as it is already.

Quote:
 Just use vertex arrays and be done with it. Display lists are not the recommended batching method.

I will try vertex arrays and VBOs later on. Thanks for the idea.

yeah, display lists will work fine actually, but it's odd that your drawing is static though you have a constant width for your lines. technically, they would have a constant width on the texture, not if you zoomed out. so i am thinking you mean the lines increase in size as you zoom out. i think you can still change the line width outside of the display list though (not 100% on that).

a screenshot may help here, it's hard to tell what the issue is here with the posted code.

1. 1
Rutin
35
2. 2
3. 3
4. 4
5. 5

• 12
• 14
• 9
• 9
• 9
• ### Forum Statistics

• Total Topics
633340
• Total Posts
3011421
• ### Who's Online (See full list)

There are no registered users currently online

×