[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:54 AM, Mark Callow <[email protected]> wrote:
If you use the same sampler type the implementation has to figure out at run-time what type of image it is sampling and may have to recompile the shader when switching between yuv and rgb images.
I understand the reasoning for the separation in the shader.
It's not wonderful either way but I believe that the majority of applications will know in advance which textures will use dynamic sources. So I think the separate sampler type is the way to go. The underlying OES extension made the same choice.
I think that most code does not have foreknowledge of what kind of source it is going to sample. For instance:
- three.js does not know until a sampling source is set, necessitating a shader recompile at that time
- kick.js does not know until a sampling source is set
- radiapp does not know, and does not contain provisions to produce different shaders, it's current code is based on the copy semantics, therefore its shader infrastructure works regardless.

Most frameworks/engines hitherto do not make any provision of having to recompile shaders on-line for sampler types, and most will have a hard time doing that.

I am toying with the idea of writing a few tools around generative/dynamic texturing, which often takes the form of processing nodes in a graph (as does radiapp). Because compiling shaders on-line is largely infeasible (due to large possible delays) the shaders would have to be pre-compiled. In the case of a 2-operator node, that would result in 4 shaders instead of one, quadruppling the shader compile time. In case of trinary or tertiary operators, it would 8x or 16x the shader compile time.