Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Currently, I'm calling glGetError() after each OpenGL function call in order to be able to detect and report bugs.

I've been reading that glGetError() calls should be reduced to once per frame in release builds. But if I do this and something does not work properly I won't be able to report where the code is failing, I would get an exception report saying that something related to OpenGL is not working properly but I wouldn't be able to detect where the code is failing.

What are the most common aproaches to report errors related to OpenGL? Should I keep all the glGetError() calls or should I call glGetError() just once per frame?

share|improve this question
up vote 2 down vote accepted

glGetError is slow on Android and should be avoided. Something you can do is create a LoggerInterface, which is called for each method call. Put a dummy implementation that does nothing in you release code, and a real one in your lab (which calls glGetError). In release code, check glGetError once per frame, and activate the real LoggerInterface for the next frame if an error is found (And save the log somewhere you can send it back to you).

share|improve this answer
I like this approach. I'm marking it as the accepted answer because I think this solution is better for my needs than the previous one. Thanks! – miviclin May 3 '13 at 22:29

I assume you're talking about running the code on the end user's machine, not just for testing.

You definitely should not call glGetError after every GL function call. You cannot know how it is implemented in certain drivers or how it will be implemented in the future. As a practical example, on NaCL (and possibly anywhere using Google's WebGL implementation on Windows) it's terribly slow as it halts some kind of multithreaded execution.

Ideally, of course, you shouldn't need to call it in release mode ever, because there shouldn't be any bugs in your code, and all dynamic input should be validated upon loading. Are you sure you cannot guarantee this? Remember that having a graphics error is about as likely as having any other kind of programming error, yet you don't attempt to run some kind of debugger in release mode.

If you absolutely need to call it, you could call it once per frame, and if you catch one, call it once per GL call and see if you can pinpoint the error. But honestly this method may fail anyway. Alternatively you could have the end user decide to run in "error report mode" or whatever you may want to call it.

share|improve this answer
I can guarantee that my GL code works in the devices that I use for testing (my library is for android), but due to android fragmentation I'm not sure if everything will work properly in all devices. But maybe I am overthinking this and, as you said, I should treat GL bugs like any other bug. – miviclin Apr 28 '13 at 20:56
Actually it is quite common to release games with some level of debugging in the code. Some games have a switch somewhere to turn debugging on or off, in some games it is always on, some even ship two executables, one with debugging, one without. Getting proper data on errors can be really valuable. – aaaaaaaaaaaa Apr 28 '13 at 21:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.