Matrix speed

my experience shows that readbacks (all kinds of) are most likely slower.

OpenGL should perform its matrix operations on the GPU which should be able to do it faster than your general purpose cpu can.

However reading back data from the Graphicscard can be quite slow, thus if you need to access the matrix of a specific object for physics etc it might be better to do the calculations on the CPU.

Your solution is not ideal.

However, it's not ideal because you're avoiding the problem (seems like you don't know the format and conventions of OpenGL's matrices, and you won't do the research to find out, or don't want to implement/understand the math involved in writing your own matrix implementation), not because of performance.

Quote:

OpenGL should perform its matrix operations on the GPU which should be able to do it faster than your general purpose cpu can.

The only on-GPU operations that will be performed are those that actually transform actual vertices that have been submitted to the card. The functions affecting the stack, like push, pop, translate, rotate, et cetera, simply perform CPU-side multiplications on CPU-side data, and consequently...

Quote:

However reading back data from the Graphicscard can be quite slow, thus if you need to access the matrix of a specific object for physics etc it might be better to do the calculations on the CPU.

Quote:

my experience shows that readbacks (all kinds of) are most likely slower.

...there are no GPU-to-CPU readbacks going on when you call functions requesting matrix stack state. You're both correct in that such readbacks can be slow, but reading the matrix state will only be slow insofar as it's a completely unnecessary function call that costs you a handful of cycles.

Whether or not those handfuls of cycles add up in the long run and eventually impact you depends on the exact nature of your program and code; but the deeper problem here is that you're trying to hack up a solution.

I do know matrix math. And do know how transformation matricies work. What I did not know is that OpenGL works with transposed rotation matricies. I said I used OpenGL's own functions. But I am still curious as to what the speed difference is.

OpenGL doesn't work with transposed matrices, it stores them conventionally in a format that might look transposed, depending on how you approach it -- but all its matrices are stored thusly, not just rotation. See this page for discussion.

The speed hit, as I said, will be minimal in isolation. Over time it might add up; you'd have to profile and see.

Even if you do know what you're doing, the solution is inelegant because its so roundabout, and certainly wouldn't be faster, so I would still advocate for something more direct and clear.

I agree with jpetrie. The forums are full of people who rely on the driver for matrix math, and many of them failed earlier or later due to missing clarity.

BTW, IMHO the code _is_ a bit ineffcient in that

glPushMatrix();glLoadIdentity();glMultMatrixd(matrix);

effectively is the same as

glPushMatrix();glLoadMatrixd(matrix);

but performs a matrix-matrix multiplication (I suspect that the driver tracks whether the current matrix is identity, but perhaps it does).