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

Re: [Public WebGL] WEBGL_dynamic_texture extension proposal

On 06/07/2012 02:04, Gregg Tavares (社用) wrote:
Looks good Mark.

A few comments:

*) is naming all the functions dynamicTextureXXX redundant? The functions are called off the extension object so

var dynamicTextureExtension = gl.getExtenion("WEBGL_dynamic_texture");
dynamicTextureExtension.setSource(texture, src);

might be enough?
If it remains solely an extension then yes but I was considering the cases of going directly into core and eventually going into core. Do you want the method names to change then?

Handling extensions that move into core is something I don't think we've discussed. In native OpenGL it is easy to provide undecorated names when and extension moves into core while also maintaining the decorated names for a while.

*) does dynamicTextureGetSource seem un GL like?

Maybe getDynamicTextureParameter(param) in case something needs to be added later?
I don't see a need. There's only one texture type so getTextureParameter() can be used. The un-GL-like point about dynamicTexture[GS]etSource is the direct access to the texture object instead of having to bind it first. If we want to continue the direct access direction and expect more dynamic texture related parameters getDynamicTextureParameter(tex, param) would be better.

*) is the state before calling dynamicTextureAquaireFrame or after calling dynamicTextureReleaseFrame desirable?

It means the behavior of the program is implementation dependent. It could be that on some browsers, never calling either function works perfectly and on other browsers or platforms it performs poorly or not at all. Where as if there is no dynamicTextureReleaseFrame and you're required to call dyanicTextureAcquireFrame to see anything at all it seems more likely you'd get consistent behavior across implementations?
Are you saying that between *ReleaseFrame and *AcquireFrame the sampler should return (0,0,0,1)? API and spec-wise that's fine. I'm not sure how to implement that on top of OES_EGL_image_external. If it's implementable, I'd be in favour.