Weird glGetError 1286

[User137]

I did some tests long ago about displaylists, and found that they draw faster than other methods. Idea is similar to compiled code and interpreted code, where you normally would have own rendering class code to manage materials, textures, polygon groups etc. With displaylist only "recorded" real rendering related actions are done, and you can free all the model data arrays from memory. There was always a performance gain even if just glDrawElements or glDrawArrays being the only call in the displaylist. Found VBO's much harder to use.

I'll see if i can narrow it further. I did go through the displaylist code though, things should be done in correct order. Also, would graphics be seen at all if there weren't clientstates? It seems to be standard way to use them
http://www.songho.ca/opengl/gl_vertexarray.html

Update: Narrowed it down to displaylist behavior. If i only draw the cube without using displaylist, no errors appear. Then when i executed glGetError after every line in displaylist creation code, it triggered exactly after glDrawElements().

I can't really find that anyone else would have ever used displaylist to draw vertexarrays. They're like exclusive methods. What i did find is
http://www.songho.ca/opengl/gl_displaylist.html

Note that not all OpenGL commands can be stored into the display lists. Since display list is a part of server state, any client state related commands cannot be placed in display list, for example, glFlush(), glFinish(), glRenderMode(), glEnableClientState(), glVertexPointer(), etc.

However even when i tried to move enable and disablestates outside of displaylist, it gave same error. So i suppose i have to stop using displaylist and vertexarray same time.

That has another interesting point:
http://www.opengl.org/archives/resou...isplaylist.htm

However, in most implementations, there's also some memory that's needed to manage the display lists of a given context and other overhead. In certain pathological cases, this overhead memory can be larger than the memory used to store the display list data!

Now updated demos to SVN too. Case should be solved (I won't mix displaylists with vertexarrays now on.)