[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@example.com> 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.
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.