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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
