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 <[email protected]> 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 > [email protected] [email protected] > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Mesa3d-dev mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > >
------------------------------------------------------------------------------
_______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
