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

Re: [Public WebGL] WEBGL_dynamic_texture extension proposal

On 06/07/2012 06:02, Chris Marrin wrote:

There are a couple of inconsistencies:

1) The IDL says "dynamicTextureAcquireImage" and the description says "dynamicTextureAcquireFrame". Same for release.
Fixed. Thanks. The search/replace in my XML editor when I decided to change the name, missed these because they are element attributes.

2) dynamicTextureSetSource passes the texture in the IDL and description, but not in the example.
Also fixed.
Given the nature of OpenGL, seems like you should not pass the texture, but rather use the currently bound texture? Same would be true of all the other API calls.
Yeah. See issues #3, #4 & #9, currently unresolved.

I was thinking that an app. might have dynamic textures on several texture units and doing activeTexture/bindTexture on each in order to call acquireImage was a bit much. This led me to pass <texture> to acquireImage. Once I'd done that, I decided to make setSource direct access as well.

I am also concerned about timestamping. ...

Your proposal doesn't deal with timestamps, so it's possible to get out of sync with the decode rate, causing strobing or other undesirable effects.
How do you handle this today when an HTMLVideoElement is passed to texImage2D?

I'm not sure that strobing, etc. will really be a problem. Basically the images are triple buffered, as Gregg described upthread, and you will always get the latest available frame. The worst that will happen is a few dropped frames. If the app. is drawing so fast it gets the same video frame more than once in succession, I don't think that is a problem.

But you bring up a good point and this definitely needs consideration.