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

Re: [Public WebGL] WEBGL_dynamic_texture extension proposal

On Thu, Jul 12, 2012 at 12:54 AM, Mark Callow <[email protected]> wrote:
> 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?

Is <http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/>
of use to anything except WebGL apps?

> 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.

The browser has a handful of metrics useful to the page for estimating
time-to-render latency. The page ultimately knows best, though,
especially with more elaborate texture pipelines and shader program
changes. Is passing a time offset in milliseconds to Acquire

Exposing machine-dependent time-to-render latency heuristics seems
like a separate interface (host profile) from dynamic texture binding.

"webglDynamicTextureOnAcquire(WebGLRenderingContext, WebGLTexture)" is
probably not going to cause name collisions or other heartache. Why
not ask for forgiveness rather than permission?

>> 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.

If we have different sampler types (RGB and YUV), we have different
sampler types. The present 'samplerExternalOES' type conflates two
separate aspects of external textures: lack of mipmap/LOD support and
colorspace conversion.

Perhaps "samplerExternalYUV" should be introduced if you want to
expose YUV colorspace to shaders? A function 'convertColorspaceRGB'
could be provided to produce 'samplerExternalRGB' from
'samplerExternalYUV' or 'samplerExternalRGB' (or 'sampler2D' from
'sampler2D' (identity)).

Consider: what if I have two videos with two different colorspaces
that I alternately bind to the same sampler? What if an author wishes
to operate on the raw YUV data (or YIQ, HSL, HSV, xvYCC, YPbPr...)? If
HTMLVideoElement decodes into a number of different colorspaces and
the conversion functions are pushed into user shaders, the conversion
permutation issue is still present if the sampler types are not
disambiguated and different HTMLVideoElement source media are bound.

>> Is the core TEXTURE2D functionality a subset of
>> WEBGL_dynamic_texture's functionality?
> No. The TEXTURE2D functionality makes a copy of the source image.

Is this (lack of) copy functionally observable? Why is a TEXTURE_2D
not equivalent to a paused video? Or an infinite video with static
frame data? The traditional TEXTURE_2D functionality that allows
mipmapping appears to be a functional subset of a "samplerExternalRGB"
to the extent that

#define samplerExternalRGB sampler2D

Should convert a shader that expects RGB external textures into a
shader that expects TEXTURE_2D textures thanks to the ad hoc
polymorphism of the overloaded texture2D functions.

>> 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.

I suggest hyperlinking into the OES_EGL_image_external specification
that amends the OpenGL ES 2.0 API.

Is conversion of all specifications into a standard hypertext format
on Khronos' agenda?

>> 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.

What you describe appears to be the opposite of the "standard
practice" WebGL has adopted. Extension names in the JS API do not have
"GL_" while OES_standard_derivatives is called
"GL_OES_standard_derivatives" in GLSL
The proposal under discussion does not use the "GL_" prefix in GLSL.

This seems like a crufty name mismatch that is no longer relevant in
the Web environment.

> 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.

OpenGL shaders can be modern and WebGL shaders can be legacy if they
use up-to-date names or deprecated names, respectively. I am
interested in compatibility and automatic roll-forward.

>> Alternately, a programmatic means to retrieve GLSL extension names
>> from JS extension names at run-time could be specified.
> An alias seems much simpler.

The extension specification should state all names that the extension
has been used under in the past and which name is
preferred/nondeprecated. The simplicity of aliases is counterbalanced
by the semantic mess they make. The semantic mess is easily resolvable
with accessible name maps.

Extensions that used vendor prefixes in draft should continue to list
those vendor prefixes that were used for the extension in the past
even if those vendors no longer accept the vendor-prefixed names as
the extension has been made official. In this way, the meaning of
software written against a draft extension can be mechanically

Openly yours,


> Regards
>     -Mark
> --
> 注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、
> 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます。
> NOTE: This electronic mail message may contain confidential and privileged
> information from HI Corporation. If you are not the intended recipient, any
> disclosure, photocopying, distribution or use of the contents of the
> received information is prohibited. If you have received this e-mail in
> error, please notify the sender immediately and permanently delete this
> message and all related copies.

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl