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

Re: [Public WebGL] WEBGL_dynamic_texture extension proposal

On 06/07/2012 02:43, Florian Bösch wrote:
On Thu, Jul 5, 2012 at 7:39 PM, Gregg Tavares (社用) <[email protected]> wrote:
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.
The only way this texture type can be accommodated without breaking all existing shaders and forcing everybody to adopt shader preprocessors as well as forcing everybody to define their sampler types up front for this flavor is to *copy* so we can get it into a texture that we can drop into our existing frameworks/libraries/utilities that just works. If the aim of this extension is to get rid of the copy, than that is mostly a failure, except for border-use cases where people incidentially have a friendly and simple enough app structure and framework so that works.
I strongly disagree that frameworks can't handle this. As long as the framework provides a way for the application to tell it what type of texture image it wants to use, many frameworks will be able to handle the separate sampler type without major problem. Existing frameworks of course have no mechanism for the app. to indicate the type of texture image so they will require modification.

I also strongly disagree that the cases where a framework (designed for handling dynamic images) would not need to copy are "border-use cases." The impetus for drafting this proposal was a discussion with a set-top box maker who needs to avoid the copy. (Isn't set-top box a ridiculously out-dated _expression_; who has a TV set any more with a top on which anything can be placed?)

Due to the architecture of OpenGL, the only time a check and recompile can be done, if a single sampler type is used, is during the draw call. I don't see any way to change that as uniform values can be changed at any time. Such a check would slow down every application.

Even if a single sampler type is used, the end result will be multiple program binaries that need to be stored so it does not save a whole lot compared to an app. or framework providing multiple shaders up front. I also think it is likely that you'll want a different fragment shader for your video textures anyway, regardless of the sampler type.