What I meant was of use to anything but WEBGL_dynamic_texture?On Thu, Jul 12, 2012 at 12:54 AM, Mark Callow <callow_mark@hicorp.co.jp> wrote: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?
Do the browsers currently expose these metrics to JS apps? If so, where is the API documented?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 insufficient? Exposing machine-dependent time-to-render latency heuristics seems like a separate interface (host profile) from dynamic texture binding.
I've done something like this in the latest draft I've added dynamicTexture{Set,Get}ConsumerLatencyUsec methods that should ideally be on the HTMLVideoElement or HTMLMediaElement. Currently they take an HTMLVideoElement as a parameter."webglDynamicTextureOnAcquire(WebGLRenderingContext, WebGLTexture)" is probably not going to cause name collisions or other heartache. Why not ask for forgiveness rather than permission?
This is deliberate.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.
A separate sampler type was chosen so as to enable implementations that may wish to insert code that does run-time selection of a shader branch to handle an external texture format without burdening all texture accesses with that extra code.Is this (lack of) copy functionally observable? Why is a TEXTURE_2D not equivalent to a paused video?
I did that in the latest draft.I suggest hyperlinking into the OES_EGL_image_external specification that amends the OpenGL ES 2.0 API.
I don't think anyone has much enthusiasm for converting the roughly 700 page OpenGL specification from TeX to whatever you mean by "standard hypertext format." We did once plan to move all the specifications to DocBook format but the idea did not gain traction. From my own experience of using DocBook for a relatively simple document I can understand why. It can be an absolute nightmare to change even seemingly simple things.Is conversion of all specifications into a standard hypertext format on Khronos' agenda?
You are quite correct about the standard practice. I was incorrect. The specifications I was looking at that did not have GL_ in the #extension strings were incorrect and have now been fixed.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 <http://www.khronos.org/registry/webgl/extensions/OES_standard_derivatives/>. The proposal under discussion does not use the "GL_" prefix in 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.