opengl - 什么时候应该调用 glGetError？

Question

glLoadIdentity说

GL_INVALID_OPERATION如果在 的执行和 的相应执行glLoadIdentity之间执行，则生成 .glBeginglEnd

但是GL_INVALID_OPERATION是glGetError返回的标志。

我的问题是，我们应该什么时候打电话glGetError（为了知道我们是否以正确的顺序调用opengl）？

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.

Answer 2

通常，您应该glGetError在每个其他gl...调用之后调用，因为调用的效果之一是从堆栈中清除错误（来自 MSDN）：

发生错误时，错误标志设置为适当的错误代码值。在调用 glGetError、返回错误代码并将标志重置为 GL_NO_ERROR 之前，不会记录其他错误。

glBegin但是，glEnd如果您glError在glEnd. 这应该会返回正确的错误代码（如果有的话）并清除错误堆栈。

Answer 3

一些编码哲学期望每个程序检查每个可能的错误，并适当地处理这些错误。然而，遵循其中一种理念需要大量额外的代码，并且会显着减慢程序的速度。在实践中，我只在诊断问题时使用 glGetError，或者编写一些很有可能失败的代码以及错误后的适当操作。

在第一种情况下，诊断问题时，我使用两种策略中的一种。因为在调用 glGetError 之前 OpenGL 不会记录新错误，所以我可以每次通过我的主循环检查一次错误。这告诉我第一个错误，然后我会追踪它，并希望能修复。当我缩小到一些有问题的代码时，我使用的另一种策略，但我不确定是哪个调用导致了问题。在每次 gl... 之后调用 glBegin 。. . glEnd 块我将调用 glGetError，并报告任何错误。这将准确地告诉我是哪个 gl... 调用导致了问题，并希望让我走上修复之路。

在第二种情况下，为可能的错误进行防御性编程，我将调用 glGetError 来清除错误标志，进行其他 gl... 调用，然后调用 glGetError。然后我采取任何必要的行动来处理任何 glGetError 报告。