[Mesa-dev] [PATCH 2/8] osmesa: remove useless osmesa_update_state() call

[Timothy Arceri]

On 08/06/17 00:58, Brian Paul wrote:
> On 06/07/2017 12:01 AM, Timothy Arceri wrote:
>> As far as I can tell this shouldn't do anything as we were just
>> passing a state of 0.
>> ---
>>   src/mesa/drivers/osmesa/osmesa.c | 2 --
>>   1 file changed, 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/osmesa/osmesa.c 
>> b/src/mesa/drivers/osmesa/osmesa.c
>> index a3d4fac..fe0326d 100644
>> --- a/src/mesa/drivers/osmesa/osmesa.c
>> +++ b/src/mesa/drivers/osmesa/osmesa.c
>> @@ -1001,22 +1001,20 @@ OSMesaMakeCurrent( OSMesaContext osmesa, void 
>> *buffer, GLenum type,
>>
>>   #if 0
>>      if (!(type == GL_UNSIGNED_BYTE ||
>>            (type == GL_UNSIGNED_SHORT && CHAN_BITS >= 16) ||
>>            (type == GL_FLOAT && CHAN_BITS == 32))) {
>>         /* i.e. is sizeof(type) * 8 > CHAN_BITS? */
>>         return GL_FALSE;
>>      }
>>   #endif
>>
>> -   osmesa_update_state( &osmesa->mesa, 0 );
>> -
> 
> Did you test this?

No, I have no idea how to test it.

This blocks patch 4, however it seems it would be safer to drop this 
patch and just create a wrapper around osmesa_update_state() in patch 4.

I'll do that instead, Thanks.

> 
> I agree that it looks like this should be a no-op, but in 
> _tnl_InvalidateState() there's a bunch of stuff that's done even if 
> new_state==0. >
> I don't have time to test this for you.  I know there are several 
> parties that still use this OSMesa driver and they'll come knocking if 
> we break it.
> 
> I'd rather leave it alone than risk a regression, unless you can do 
> sufficient testing. >
> -Brian
> 
> 
>>      /* Call this periodically to detect when the user has begun using
>>       * GL rendering from multiple threads.
>>       */
>>      _glapi_check_multithread();
>>
>>
>>      /* Create a front/left color buffer which wraps the user-provided 
>> buffer.
>>       * There is no back color buffer.
>>       * If the user tries to use a 8, 16 or 32-bit/channel buffer that
>>       * doesn't match what Mesa was compiled for (CHAN_BITS) the
>>
>