Order of push/popGLstate in Rendertarget

[Eelco]

Hi there,
In my persuit of solving problems combining sfml2d and own opengl 3d I started working through the sources of sfml.
I checked the Graphics Rendertarget and stumbled over the folowing that I do not understand: The order of push/pop in pushGLStates and PopGLStates. I pasted the code below.

I would expect the order of the pop to be the reverse of the push, but that is not happening. Could anybody explain why this is not so? (I'm probable overlooking something here  )

push: ( clientattrib, attrib,) modelview, projection, texture
pop: projection, modelview, texture,  ( clientattrib, attrib,)

I would expect: pop: texture, projection, modelview,  ( attrib, clientattrib)

Thanks in advance

////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
void RenderTarget::pushGLStates()
{
    if (activate(true))
    {
        #ifdef SFML_DEBUG
            // make sure that the user didn't leave an unchecked OpenGL error
            GLenum error = glGetError();
            if (error != GL_NO_ERROR)
            {
                err() << "OpenGL error (" << error << ") detected in user code, "
                      << "you should check for errors with glGetError()"
                      << std::endl;
            }
        #endif

        #ifndef SFML_OPENGL_ES
            glCheck(glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS));
            glCheck(glPushAttrib(GL_ALL_ATTRIB_BITS));
        #endif
        glCheck(glMatrixMode(GL_MODELVIEW));
        glCheck(glPushMatrix());
        glCheck(glMatrixMode(GL_PROJECTION));
        glCheck(glPushMatrix());
        glCheck(glMatrixMode(GL_TEXTURE));
        glCheck(glPushMatrix());
    }

    resetGLStates();
}


////////////////////////////////////////////////////////////
void RenderTarget::popGLStates()
{
    if (activate(true))
    {
        glCheck(glMatrixMode(GL_PROJECTION));
        glCheck(glPopMatrix());
        glCheck(glMatrixMode(GL_MODELVIEW));
        glCheck(glPopMatrix());
        glCheck(glMatrixMode(GL_TEXTURE));
        glCheck(glPopMatrix());
        #ifndef SFML_OPENGL_ES
            glCheck(glPopClientAttrib());
            glCheck(glPopAttrib());
        #endif
    }
}

[binary1248]

Because it doesn't have to be in reverse order.

We have to push 3 matrices and pop 3 matrices. We can't do it simultaneously so there has to be an order. The order is irrelevant since pushing and popping matrices has no side effects. The only one who would care about the order is the user, since the last operation will determine the currently active stack at the end of each call.

Since we don't explicitly check which stack was active when pushing, and try to restore that one last when popping, we assume the user will always activate a stack themselves before performing any matrix operations. We could save it for convenience, but we simply don't bother.

Legacy OpenGL won't last forever, and one of the things to go with it is the matrix stack. There isn't much sense optimizing for something that is far from optimal to begin with. If you want fast OpenGL code, use modern OpenGL.

[Eelco]

Ok, tnx binary1248 for your speedy reply ,
this helps getting things clear.
And I'm indeed already using modern opengl, opens a universe of opportunities for a graphics programmer