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

Re: [Public WebGL] WEBGL_dynamic_texture extension proposal



On Thu, Jul 5, 2012 at 8:57 PM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
>
>> 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.

The variants of dynamicTextureSetSource imply that HTMLCanvasElement,
HTMLImageElement, and HTMLVideoElement share an interface supporting
dynamicTextureAcquireImage and dynamicTextureReleaseImage. What is
this interface?

> I do not understand "dual to the IDL ...".

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?

>> 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 there is no penalty, then WEBGL_dynamic_texture defines a superset
of the core texture functionality. By using only
WEBGL_dynamic_texture, fewer distinct paths are exercised, fewer
special cases are necessary, and the texture interfaces are unified.

By defining the present texture functions in terms of
WEBGL_dynamic_texture, WEBGL_dynamic_texture is understood to expose
previously implicit locking to the application. Future implementors
are then able to directly implement WEBGL_dynamic_texture and provide
the core WebGL texture functions as a subset of this interface in a
standard way.

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

Is the core TEXTURE2D functionality a subset of
WEBGL_dynamic_texture's functionality?

>> 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
>> tag?
>
> Yes please. I hadn't even noticed that using <keyword> meant the type didn't
> appear in the generate HTML.

The patch is attached to the bug
<https://www.khronos.org/bugzilla/show_bug.cgi?id=669>.

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

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?

>> 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
>> "WEBGL_dynamic_texture"?
>
> See issue #5. How would you make the connection "more prominent?"

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.

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. Aside:
using URIs to identify extensions would enable the construction of
generic shader analysis tools to perform this update and future
updates like this automatically.

Alternately, a programmatic means to retrieve GLSL extension names
from JS extension names at run-time could be specified.

Regards,

David

>> Do you foresee any more extension name
>> contexts besides JS and GLSL?
>
> No.
>
> 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 public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------