I am writing my first display list and wonder how matrix manipulations are handled performancewise.
Lets say I in the display list write the following:
When the display list is created is the 4 matrix commands then collapsed into a single matrix or does this not happen until the display list is actually executed. What I means is what it pay at run-time to change the above to:
calculate my own matrix
Thanks in advance,
The internal behavious of the display list is implementation dependent. All you need to care about it that after the displaylist is executed, the contents of the active matrix stack will be reset, translated, rotated and scaled. How these four commands are executed is nothing you should care about.
Well I do care, because those display lists are executed quite often, but the display list needs only to be created once. So if the matrices are multiplied every time the display list is executed then I would rather extract the calculations to display list creation time.
I don’t really get what you’re doin. If you are drawing the display lists several times, the object will always appear in the same spot, assuming you don’t change the projection matrix, and always have the modelview stack active. Then why not compile the matrix functions into one display list, and the object in another display list? Call the matrix list once, and the object list several times.
If performance is of great importance, there are much more places that needs more optimization that combining four matrices to one.
Okay let me explain. I have a high number of objects each consisting of about 10 triangles. Each object is positioned independantly of each other and have each their set of transformations which remains the same most of the time but does change rarely. I have a display list for each of these objects.
The point is that if there is 3 extra matrix multiplications for each object each frame then this adds up quickly.
To sum up my question, does any OpenGL implementations perform optimazations on the dipslay list before it is executed to remove unneeded commands at execution time?
As I said in my first post: It’s up to the implementation to choose if it feels like combining it to one or not. You don’t, and probably never will, know what happens once the command has reached the driver.
Anyways, now when you explained the situation a little bit more, I see why you ask. If you really feel like it, you can combine the four matrices yourself. But you can ask yourself if it’s really needed. Have you really seen any performance hit doing the four commands compared to one combined? I mean, we’re only talking about three matrix multiplications (and the overhead of a matrix multiplication, but dunno how large), but compared to other things you do in a application, this is really nothing.
And another thing that I wondered about. You said the object most of the time is static. Does this mean that one in a while you recompile the display list, just to update the matrices? If that’s the case, I strongly recomend you put the object and the matrices in two different display lists. And since you only have the matrix stuff in a display list then, do the matrix stuff right away, and save a display list.
Hmm, thanks for your suggestion.
I think I will end up with another solution. Since the objects only move very rarely I think I will implement my own matrix stuff and then apply them directly to the object data. This means that the display lists becomes completely void of matrix operations since those are moved to display list creation time - that allows me to avoid changing the MODELVIEW matrix state at all - something that makes sense since the objects only rarely move.
I am not an optimisation guru but this suggestion might help. Each time you have to recreate the display list do your matrix multiplications before creating the list, then start creating the list, load the final matrix and end the list. This way the list can only store the final value instead of possibly storing the multiplications.
I also agree with keeping the matrix calculations in a separate list from the image. This gives more flexibility in how they are combined and can reduce any performance costs.
[This message has been edited by Furrage (edited 01-25-2002).]