Question

glLoadIdentity says

GL_INVALID_OPERATION is generated if
glLoadIdentity is executed between the
execution of glBegin and the
corresponding execution of glEnd.

But GL_INVALID_OPERATION is a flag returns by glGetError.

My question is, when should we call glGetError ( in order to know whether we are calling opengl in correct sequence)?

Answer 1

I’m not sure if your question is about when you can call glGetError if inside glBegin/End or whether it’s a more general question about glGetError usage in general. So I’ll answer both.

What you can do between glBegin and glEnd is very limited. This is on purpose, as you put the GL in a very specific mode – in the middle of a Draw. As such, anything that does not relate directly to per-vertex attributes is simply invalid. Even a glGetError is invalid in that context.Try and think of glBegin+all the GL calls in between+glEnd as a single Draw call to the GL, that helps get closer to what the GL really does anyways.

Now, you should never really have a GL error triggered while inside the Begin/End pair if you stick to the simple rule to only call attribute methods (glNormal, glTexCoord, glColor, glSecondaryColor, glIndex, glMultiTexCoord, glVertexAttrib, glVertex and a couple others). Anything else will trigger an error. (err… well, glMaterial is a bit of an exception. It works, but its usage has been discouraged)

If your question is when you can call glGetError when the error was triggered inside a Begin/End pair, ChrisF answered in a comment: after the glEnd call.

Now, in a broader sense, use glGetError only as a debugging tool. My personal bias is twofold:

• check glGetError once per frame to be sure there is no error
• wrap most GL calls with a macro that can check the GL error code, and only turn it on when the per-frame check fails.

Of course, since the attribute methods can be called outside a Begin/End pair, it’s a bit tricky to get them right. But in practice, those methods never fail anyways, so I don’t bother to macro-check them.

A tidbit of trivia: the GL API was originally designed so that the client implementation could actually not know whether there was an error at the call site. E.g. if the GL was actually implemented in a remote machine (like in the SGI days), a call to, say, glTexEnv with a target not of GL_TEXTURE_ENV could simply be added to the command buffer, and no error would be recorded at that point.

If you then called glGetError, the client side would then have to flush the command buffer to the GL server, wait for the commands that are buffered to be processed, get the error code back, and return the appropriate error code to the application.

If this sounds heavy, that’s because it was. This was the main reason why not each call was returning an error code, by the way, and why calling glGetError was only considered ok for debugging purposes. These days, most GL implementations are handling all the state management in the same process, so as I said, it’s really trivia for most users.

Last, whenever I’m talking about Begin/End, I feel I need to say that you should probably look at not using it at all. It’s about the worst performing way to Draw with GL.