glEnable() vs glEnableClientState() is a big deal when Xserver != Xclient, in theory. I can verify that on Win32/NVidia that replacing **only** glEnable/DisableClientState(GL_VERTEX_ARRAY) with glEnable/Disable(GL_VERTEX_ARRAY) causes random polygons to flash and general corruption of the scene geometry. Replacing them again with glEnable/DisableClientState() fixes the issue. I did not try to get the error code, but seriously, if the scene turns to garbage, I could care less about whether NVidia generates an error code for it too. The manpages specifically enumerate the constants and GL_VERTEX_ARRAY just isn't there.
Patrick
On Sun, Jul 5, 2009 at 10:02 PM, Eric Anholt
<eric@...> wrote:
On Thu, 2009-07-02 at 22:20 -0700, Vinson Lee wrote:
> I believe there's a bug in the piglit vbo-map-remap.c test. The test
> fails for me with a GL_INVALID_ENUM error that comes from
> glEnable(GL_VERTEX_ARRAY). GL_VERTEX_ARRAY is a client-side capability
> so the error seems valid.
Mesa's been accepting array enums in Enable/Disable as if it was
Enable/DisableClientState since the initial revision in CVS, it looks
like. If this is in fact invalid and other vendors throw errors on it,
I'd like to see Mesa follow suit.
However, tests should be strict in what they test, so please apply.
--
Eric Anholt
eric@... eric.anholt@...
------------------------------------------------------------------------------
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
------------------------------------------------------------------------------
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev