The trouble with the development of OPENGGL is that the error finding is not good for tracking. Glgeterror () returns the first error code, noting that this is not necessarily the error code generated by the last GL function call. OpenGL error codes are processed in FIFO mode.
I was in the development of Android player (Mediacodec + OpenGL) When I encountered a very embarrassing thing, when the rk3228 run, black screen, trace out a warning:
Bingtextureimage:clearing GL Error 0x500. The beginning of time always thought is glbindtexutre error, according to the error code, as if not supported OES type of texture caused, thought is not this chip is not supported, a long time, until I saw the Surfacetexture.updateteximage () The source code knows that the warning is handled by this function, but not the function is problematic, but the previous call to OpenGL's rendering function (a heap) generated when it was cleared (so called clearing). So check the wrong focus in the rendering section, a check, and finally found the problem.
Sometimes it is not difficult to fix the problem, the difficulty is "positioning" the problem where, on the same treatment, you need to know where the lesion, and then to cure Ah!
OpenGL Error Tracking