[Public WebGL] OES_EGL_image_external Extension proposal

Mark Callow [email protected]
Wed Jan 11 22:43:05 PST 2017

> On Jan 11, 2017, at 2:16, Byungseon Shin <[email protected]> wrote:
> Hi Mark,
> Thanks for the in-depth feedback.
> I agree your opinions and have changed the logic by your guide.
> I have created a new patch and please review it again.
> https://github.com/KhronosGroup/WebGL/pull/2243/commits/c8193b5f1ffb37881bb815bd98b4da91e516828d <https://github.com/KhronosGroup/WebGL/pull/2243/commits/c8193b5f1ffb37881bb815bd98b4da91e516828d>
> About the OES_EGL_image_external_essl3, we will follow up soon.

Thanks updating the spec. I am not comfortable with calling this OES_EGL_image_external and especially not with reusing the function name EGLImageTargetTexture2DOES. I think you are really wrapping the OES extension NV_EGL_stream_consumer_external <https://www.khronos.org/registry/gles/extensions/NV/NV_EGL_stream_consumer_external.txt>. This is actually what WEBGL_dynamic_texture is wrapping.

I also wonder if using the same function for initial setup and for latching each frame is a good idea. The work to be done will be different so there should be different functions.

I think it would be better to go back to WEBGL_dynamic_texture, simplify it a bit by changing its WDTStream class to be a bit more like Android’s SurfaceTexture and adding the essl3 support.

I know at first glance WDT looks way more complex than this current proposal but that is because it documents precise detailed behavior while the current proposal still leaves a lot to the imagination. The only real functional difference is the presence of a call to set the presentation time of the drawing buffer. This function is also the area of greatest concern for browser vendors. I note though that Android’s MediaCodec class provides this capability via its releaseOutputBuffer(bufferId, timestamp) <https://developer.android.com/reference/android/media/MediaCodec.html#releaseOutputBuffer%28int,%20long%29> method.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170112/1df691e7/attachment.html>

More information about the public_webgl mailing list