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

Re: [Public WebGL] OES_EGL_image_external Extension proposal

On Jan 11, 2017, at 2:16, Byungseon Shin <sun.shin@webkit.org> 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.

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