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

Re: [Public WebGL] WEBGL_dynamic_texture extension proposal



On 07/07/2012 06:04, David Sheets wrote:
...
This would be the common texture source interface that each texture
source implementation supplies to support the WEBGL_dynamic_texture
IDL. WEBGL_dynamic_texture introduces new texture pipeline operations.
Can both sides of this interface be standardized in this extension?
Ahh! I understand now. Would making this interface public be of use to anything bar WebGL app's? In any case,
I don't think this group can standardize these interfaces. I think we'd have to propose something to WhatWG. However, we need to pursue the issue of synchronization raised by Chris before we can come up with a proposal to present to them.
If there is no penalty, then WEBGL_dynamic_texture defines a superset
of the core texture functionality. By using only
...

It also means that:

#define sampler2D samplerExternalOES

in the shader preamble solves Florian's problem if the app developer
always uses WEBGL_dynamic_texture even for static textures.
If everything was unified we'd be back to same problem of having to identify at run-time which samplers are accessing RGB data and which YUV data and having to recompile shaders. As I mentioned in an earlier post, I think we are going to have to drop the HTML{Canvas,Image}Element support from this proposal for the same reason.
Is the core TEXTURE2D functionality a subset of
WEBGL_dynamic_texture's functionality?
No. The TEXTURE2D functionality makes a copy of the source image.
The patch is attached to the bug
<https://www.khronos.org/bugzilla/show_bug.cgi?id=669>.
Thanks for the patch. I haven't had time to update the extension spec. to use it yet. I expect to do so before the end of the week.
What do you mean by "the amended OpenGL ES 2.0 API specification" in
overview bullet 2? What is the URL of this document? Does it have a
versioning scheme?
It means the OpenGL ES 2.0 API specification as amended/extended by the OES_EGL_image_external specification. I used more long-winded phraseology at first before shortening it to the above. If it's too hard to understand, please suggest something else.
Perhaps some specific generated text that explicitly states the usable
extension names in JS and in GLSL? OES_standard_derivatives has a
similar but less severe discrepancy between OES_standard_derivatives
and GL_OES_standard_derivatives.
This "discrepancy" is standard practice for Open GL {,ES} extensions. The GL_ prefix is only added to C API names in lieu of namespaces or objects. It is normal that the extension string returned in getExtensions has "GL_" while the name used with #extension does not.  I don't think we should change that practice.

However in this case the WebGL extension has a different name.
I propose making extension names in GLSL identical to those in JS and
providing GLSL extension aliases for those legacy names that do not
match. The legacy names would then be deprecated and the extension
specification XML and HTML documents would contain information
sufficient to transform a legacy shader into a modern shader. 
I would have no objection to providing an alias. I quibble with your use of "legacy" and "modern" to differentiate OpenGL and WebGL shaders though.
Alternately, a programmatic means to retrieve GLSL extension names
from JS extension names at run-time could be specified.
An alias seems much simpler.

Regards

    -Mark
--