[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL URI Extension Proposal
On Wed, May 16, 2012 at 7:25 PM, Ben Vanik <firstname.lastname@example.org> wrote:
> Agreed - as a dev I haven't felt much pain here because tools can go a long
> way towards making this stuff better, very similar to the webgl-uri library
> written here, and as user code it's much more flexible.
The webgl-uri shim is a proof of concept, not something developers
should have to concern themselves with. For tools to interoperate with
each other, we must agree on a standard way to describe non-standard
extensions (extensibility) so tools can either consume or reject
inputs intelligently without unexpected results. The browser is now
the standard consumption device for shaders and thus I supplied a
browser shim; however, shader processing tools are the primary
beneficiaries of an extension like URI.
> For example, I use a
> glsl compiler to minify and optimize my shaders
> (http://code.google.com/p/glsl-unit/wiki/UsingTheCompiler) - I'd rather have
> that spit out optimizable JS that enables extensions and does the checks at
> compile time rather than require massive strings and runtime parsing
> included in my shipped resources. As user code, something like GLSL Sandbox
> could do it at runtime, while shipped apps and games could do it much
> earlier or wherever it made sense.
I totally agree with you and that is why something like the URI
extension is needed. No runtime change is required in the vast
majority of cases because, as you point out, the resources can be
specialized early. My proposal demonstrates the uniformity of
end-to-end URI namespace mapping. That is, Khronos extension names
exist in URI-space, too, even if you never refer to them with URIs.
My proposal primarily concerns a way to declare that some shader
source code is using a specific non-standard extension.
glsl-unit implements a non-standard extension to the shading language
(crucial semantics in comments). If you were to publish your
not-yet-compiled glsl-unit shaders right now, there would be no
declaration for automation to examine to understand how to consume the
glsl-unit commands in comments. IMHO, this is a problem.
glsl-unit implements many features that other tools implement in
different ways (e.g. source inclusion). If someone else wants to
implement a tool that consumes glsl-unit's template commands as well
as some other tool's template commands (or an extension to glsl-unit's
commands), they have to sniff and special case these syntaxes without
a standard break-out hint that says "I am using concepts from
As tool developers without a blessed way to declare our language
extensions, we are harming ecosystem interoperability. Our tools can
work together and make our lives easier by cooperating if we have a
standard way to declare our non-standard extension use.
My explanations may be confusing or unclear and if you don't
understand my reasoning, please don't hesitate to ask. :-) Most likely
I have simply not explained my proposal well enough.
> On Wed, May 16, 2012 at 7:11 PM, Mark Callow <email@example.com>
>> On 17/05/2012 07:11, David Sheets wrote:
>> Seeing something like this in a program would make me think that
>> getExtension will download the extension rather than it having to be built
>> Since extensions cannot be downloaded and are implemented by a very small
>> number of people, I think the current prefixing mechanism works just fine.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: