Ugh. I wonder aloud whether it's worth it to continue supporting color index mode at all. Are any apps still using that? It's an obsolete feature in OpenGL, and basically the only reason it's still in VirtualGL is because the GPU vendors continue to support it in their drivers. But since we're in beta, no sense in removing a feature that still works.
I'd definitely prefer to not introduce a new environment variable. I think the best way to do it would be to introduce a new field in the ContextAttribs structure in ContextHash.h, as well as a new argument to ContextHash::add() (probably just a boolean specifying whether the context is CI or not.) Then you can add ContextHash::isIndex() and ContextHash::indexCurrent() straightforwardly and use those within the body of the CI emulation functions to pass through the calls if the current context isn't CI. On 9/5/14 9:02 PM, Nathan Kidd wrote: > Hi DRC, > > MSC Mentat uses an RGB visual but occasionally calls glIndexi() instead > of glXColor3f(). > > I could not find any specification to say what is supposed to happen in > that case. All the OpenGL implementations I've tested simply ignore > glIndex() on an RGB visual (glGetError() returns nothing), but VirtualGL > always emulates CI rendering and converts the index value to RGB. > > The result is that when using VirtualGL some drawing is wrong e.g. the > RGB conversion of glIndex(0) produces a black rubberband drawn over a > black background, whereas sans-VGL the previous (non-black) glColor > still has effect. > > The glIndex hooks assume that if you're calling glIndex you must have a > CI context current (from app perspective), but as above that's not > always correct. > > A possible automatic fix would be to allow the glIndex to pass through > unmodified if the current context (again, from app perspective) is RGB. > Having only glanced at the surface of this, tracking the app rendering > type perspective would seem to involve some complication of mapping the > rendering type bit used in any glXChoose*() calls to contexts eventually > created with the returned Visual/FBConfig ids. > > A simpler approach might just be VGL_CIEMULATION=0 > > Do you have any comments or preferred approach before I submit a patch? ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ VirtualGL-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
