[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Specifying the behavior of bindXXX when passed a deleted resource



Agreed.

-Jeff

----- Original Message -----
From: "Gregg Tavares" <gman@google.com>
To: "Brandon Jones" <bajones@google.com>
Cc: "public webgl" <public_webgl@khronos.org>
Sent: Friday, June 14, 2013 3:59:17 PM
Subject: Re: [Public WebGL] Specifying the behavior of bindXXX when passed a deleted resource


I'd also point out, the fact that glUseProgram etc, are supposed to generate INVALID_VALUE for ids not created through glCreateProgram suggests that the same should be true for ids passed to glBindXXX in WebGL. 


The ES 3.0 spec mentions they are trying to get rid of the resource creation on bind feature from GL in Appendix F.1 







On Fri, Jun 14, 2013 at 3:46 PM, Brandon Jones < bajones@google.com > wrote: 



I vote Yes and Yes. That seems like the most internally consistent way to handle these situations. 


--Brandon 





On Fri, Jun 14, 2013 at 3:33 PM, Gregg Tavares < gman@google.com > wrote: 



AFAICT the WebGL spec is currently silent on what happens when you bind a deleted resource. 


In other words 


var tex = gl.createTexture(); 

gl.deleteTexture(tex); 
gl.bindTexture(gl.TEXTURE_2D, tex); // What does this do? 


The conformance tests expect that to bind 0 [glBindTexture(gl.TEXTURE_2D, 0)] but the WebGL spec doesn't say that's what's supposed to happen. 


We need to update the spec but I'm also curious if we should change the behavior. Should that bind above generate INVALID_VALUE or should it stay as is and bind 0? 


The same is true of gl.useProgram. Calling useProgram on a deleted program ends up calling glUseProgram(0) but that's not in the spec. In fact it's specifically against the spec as the ES 2.0.25 spec, 2.10.1 says 




Commands that accept shader or program object names will generate the error INVALID_VALUE if the provided name is not the name of either a shader or program object and INVALID_OPERATION if the provided name identiļ¬es an object that is not the expected type. 


We either need to fix implementations and tests to match the ES spec or update the WebGL spec to document the different behavior. 


Should binding a deleted resource generate an error? My vote = yes. 
Should useProgram follow the ES spec and generate an error? My vote = yes 


Thoughts? 






-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------