Command ordering glitch with EnableClientState and ColorPointer.

[cxd4]

A couple times already, I've stumbled on a strange issue where the order of these mattered.

Really, their order shouldn't matter. The following code:

glColorPointer(number_of_channels, GL_FLOAT, stride, &vertex_cache[0]);
glEnableClientState(GL_COLOR_ARRAY);

... should be equivalent also to saying ...

glEnableClientState(GL_COLOR_ARRAY);
glColorPointer(number_of_channels, GL_FLOAT, stride, &vertex_cache[0]);

You're supposed to be able to switch the two lines around and get the same result, but I've found in some cases that only the former works with my wrapper while the latter style fails. I have yet to see the bug enough times to really pinpoint what the issue is here.

[cxd4]

I can further observe this issue by the symptom that initializing the state machine inside gl.js wrapper function init_GL_context() results in further errors and failures if either one of these is used:

glVertexPointer(4, GL_FLOAT, 0, null);
glColorPointer(4, GL_FLOAT, 0, null);

//[14:27:41.649] Error: invalid arguments @ gl.js:391

[cxd4]

Cannot seem to reproduce this issue these days.

Maybe it was fixed by accident during one of the rewrites; maybe it was a bug in the Windows driver.
I'll wait until something solid and repeatable comes up during development again.