[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 10:19 AM, Florian Bösch <pyalot@gmail.com> wrote:


On Thu, Jul 5, 2012 at 7:16 PM, Gregg Tavares (社用) <gman@google.com> wrote:
I don't expect most libraries will handle it automatically. Most will require the user to specify upfront what they want.

but yes, if they want to support dynamic textures I do expect them to handle it. Only they know when is the appropriate time to compile and when to fail. On top of that they have to call dynamicTextureAcquireFrame to use these textures so it's not like they can magically do nothing and have it just work.

Those libraries that do want to type handle it automatically are already most likely handling it dynamically. They generate shaders based on number of lights and other material parameters. The can just as easily add dynamic textures as an option to their generator.

The only remotely reasonable sane way that this extension can be "handled" by frameworks is creating ghost textures, creating an FBO, then doing a copy shader, that just uses this one sampler, copies it to an RGB texture and then drop in that RGB texture in place of this broken piece of mess. So that's fine, we can do that, no problem, I just thought, you know, maybe don't make people jump trough complicated mad hoops just to make it possible to write a sane library/framework/toolkit.

The only point of this extension is to avoid the copy. To avoid the copy videos are effectively triple buffered. Video usually has 3 textures, Y, U and V. It has those double buffered so it can be filling out one while displaying the other. This extension basically adds a 3rd buffer. Calling dynamicTextureAcquireFrame takes one of those buffers (sets of 3 textures). No copy required.

On other words. The video decoder is using

frame 1: fill in setA, draw with setB
frame 2: fill in setB, draw with setA
frame 3: fill in setA, draw with setB
frame 4: fill in setB, draw with setA

User calls dyanmicTextureAcquireFrame and is given setB. Video is now doing this

frame 5: fill in setC, draw with setB
frame 6: fill in setA, draw with setC

User calls dyanmicTextureAcquireFrame and is given setA. Video is now doing this

frame 7: fill in setB, draw with setA
frame 6: fill in setC, draw with setB

etc...

Zero copy is the whole point of this extension. If you want the copy path just call texImage2D(....., HTMLVideoElement). Browsers are already working on making that path use an FBO to speed up the copy. But it's still a copy. Copying 1920x1080p video at 60hz is a much slower and battery intensive operation than not copying at all.