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

[Brian Paul]

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?

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
>