RE: [Chromium-dev] The "lighting bug" and semaphore deadlock

[Greg H. <hu...@cs...>]

It seems like *all* of the light parameters suffer from this particular
problem.

Nice find!  This problem exists in the WireGL state tracker as well --
it's a three (four?) year old bug now!  It plagued Francois on our wall,
and only happened with parallel applications.

I'll check in a fix to the code generator after lunch.

	-Greg

P.S.  I believe this bug only affects crStateLightingSwitch, not
crStateLightingDiff, but I'm not 100% sure about that.  This would mean
that only parallel applications were affected, not tiled displays, which
is consistent with the bug's behavior.

--
Greg Humphreys, Assistant Professor
Department of Computer Science, University of Virginia
http://www.cs.virginia.edu/~humper/ 

> -----Original Message-----
> From: chr...@li... 
> [mailto:chr...@li...] On Behalf 
> Of David Thompson
> Sent: Wednesday, October 23, 2002 7:15 PM
> To: Chromium Development List
> Subject: RE: [Chromium-dev] The "lighting bug" and semaphore deadlock
> 
> 
> I have found the lighting bug! I'm not sure how to implement the
> fix in the Python code generator (or if my fix is the most efficient
> way to go about it),  but the basic problem is that calling
> 	glEnable(GL_LIGHTING)
> 	glEnable(GL_LIGHT0)
> then switching to another context and back to call
> 	glDisable(GL_LIGHT0)
> ends up setting the state tracker's state bits for light 0
> (sb->lighting.light[0].dirty) but NOT setting the bits for lighting
> (sb->lighting.dirty). So, when crStateDiffContext() or
> crStateSwitchContext() call CHECKDIRTY(sb->lighting.dirty, bitID) to
> see if crStateLightingDiff() must be called, the test fails even
> though one of the lights must be enabled/disabled to move to the
> new context.
> 
> What's worked as a fix for me is to add a "FILLDIRTY(b->dirty);"
> into state_lighting_gen.c (patch attached), but this file is
> automatically generated. The patch is against the generated file.
> 
> Could this be causing  Jesus Caban's OpenInventor color problem,
> too?
> 
> 		David
>