[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 12:47 AM, Mark Callow <[email protected]> wrote:
> I have completed the initial draft of a proposed WEBGL_dynamic_texture
> extension. The purpose of this is to provide an API for handling textures
> with dynamic images such as video that can be implemented at the maximum
> efficiency possible on a given platform, including with zero copies.
> Please look at the issues list before posting any questions as it contains
> many of the questions you are likely to have and several answers.
> You can find the proposal at:
> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture
> I welcome your comments and help to resolve all the listed issues.

This extension looks great, Mark. Thank you!

A few questions:

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.

2. Is there any performance penalty for using this functionality with
static textures vs the present texturing functions? If not, is it
possible to formulate and include a concise description of the WebGL
core texture functionality in WEBGL_dynamic_texture terms?

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

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?

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"? Do you foresee any more extension name
contexts besides JS and GLSL?



> 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