[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:54, David Sheets wrote:
1. Can the source interface be standardized to allow, e.g., WebGL
FBO-based dynamic texture sources? I would like to construct generic
WebGL rendering modules that expect something satisfying a dynamic
texture interface that isn't necessarily an HTML Canvas element. I
believe this involves defining the dual to the IDL to provide an
object with 4 functions like onSet, onUnset, onAcquire, and onRelease.
The point about this extension is that the texture images are updated outside the control of WebGL and the WebGL application. The case you describe is wholly within the GL so I do not see how {acquire,release}Image bring any benefit. Currently all you need do is rebind the texture from the FBO to the appropriate texture target.

I do not understand "dual to the IDL ...".
2. Is there any performance penalty for using this functionality with
static textures vs the present texturing functions?
Why would you want to do that?
If not, is it
possible to formulate and include a concise description of the WebGL
core texture functionality in WEBGL_dynamic_texture terms?
The core texture functionality remains unchanged. If you bind the texture to TEXTURE2D or one of the other existing targets, data is sampled from the regular image store that is set via tex{,Sub,}Image* or copyTex{,Sub}Image.
3. samplerExternalOES is a new abstract GLSL type (no constructors).
How would you like to declare this? I see right now, it is called a
"<keyword>" without HTML generation. Perhaps "<type name='...' />"
with corresponding boilerplate text? Would you like me to draft this
Yes please. I hadn't even noticed that using <keyword> meant the type didn't appear in the generate HTML.
4. <http://www.khronos.org/registry/webgl/specs/1.0.1/> doesn't exist
but is referenced from Dependencies. Where is 1.0.1 hosted?
Fixed. It should have been 1.0. I was confusing it with the CTS version.
5. If WEBGL_dynamic_texture is the name of the WebGL extension which
mirrors but restricts OES_EGL_image_external and
OES_EGL_image_external is still used in GLSL for cross compat reasons,
should this connection be made more prominent in the extension spec
text? The spec document currently has all the semantic information
necessary to extract this link. I wonder if using
WEBGL_dynamic_texture in JS and OES_EGL_image_external in GLSL
otherwise appears to casual readers as an OES => WebGL oversight.
Perhaps WebGL could create a GLSL extension alias
See issue #5. How would you make the connection "more prominent?"
Do you foresee any more extension name
contexts besides JS and GLSL?