Re: [filter-effects] New syntax proposal for 'custom' filter function

On Fri, Nov 30, 2012 at 10:48 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> Details:
>
> - the src descriptor
> We wanted to make sure that authors know the grammar and can easily adapt to CSS Shaders. The syntax of 'src' is actually the same as for the @font-face rule. The author needs to specify the url to the shader and the format of the referenced file (e.g "glsl" for CSS Shaders).

WebGL shader processors must accept UTF-8 encoded characters in source
comments. This is only an optional feature for OpenGL ES 2.0 GLSL 1.0
(but required in 3.0). I do not believe any other GLSL dialect
requires this. WebGL shader processors treat shaders without
"#version" directive as being version 1.0 of ESSL. This sort of
(justified, wonderful, modern) divergence makes "glsl" terribly
ambiguous.

Once a media subtype is chosen for the shading language, I believe
this parameter should mirror that string (i.e. "application/webglsl"
=> "webglsl" or "text/essl" => "essl" or "application/glsl" => "glsl"
(yikes)).

> The 'src' descriptor is very generic and allows "packaging" of a feature. The feature is identified by the format passed as a string. This makes Filter Effects "extensible" by other specifications. We don't need to adapt Filter Effects to extend the support. Furthermore, we just have one HTTP request instead of multiple requests as before, which is a great benefit.

A pipeline package/effect concept would definitely be useful in the
future but I am concerned about this direction for a number of
reasons:

1. A new mandatory, bespoke package format
2. A new XML vocabulary that deserves careful design to support more
than just this use case
3. Mixing and matching vertex and fragment effects becomes harder

Can I package only a vertex effect and use a default fragment shader?
Custom fragment with default vertex?

As an extension to custom CSS shaders, browser vendors may certainly
wish to implement package format support which may be indicated by the
appropriate Accept header.

> Shader description format:
>
> The new proposal requires some kind of packaging the information. We are open for solutions on the format. We could have a manifest file and the shader files in a ZIP archive. Another proposal is multi-part mimes. A solutions that we preferred is an XML document, which could look like this:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <shader>
>         <license>Apache License 2.0</license>
>         <vertexShader><![CDATA[
>                 // my vertex shader code.
>          ]]>
>         </vertexShader>
>         <fragmentShader><![CDATA[
>                 // my fragment shader code.
>          ]]>
>         </fragmentShader>
>         <parameter name="idenMat" value="mat2(1,0,1,0)"/>
> </shader>
>
> Our main goal is to make it easy to create this package. We would probably need more brain storming on the format, but would like to hear your thoughts on the general idea. Feel free to ask more questions.

As I understand it, you have two goals with this package format:

1. shader bundling for semantic grouping
2. shader bundling for network request reduction

It occurs to me that previous shader effects proposals already had
semantic grouping in the form of separate CSS properties for separate
pipeline stages in a common at-rule. In this way, CSS files with
at-rules are essentially shader composition descriptions that may be
included, imported, or preprocessed into a single stylesheet or page.
The present proposal is essentially an XML representation of the
previous at-rule proposal. Is this accurate?

In lieu of a mandatory new XML vocabulary, I propose an approach which
takes advantage of the already-present platform features of cascading
style sheet rules, fragment identifiers, media types, and/or shading
language analysis.

Some facts:

1. CSS is modular/packaged via the cascade
2. Multiple URLs with identical scheme, authority, path, and query
components but differing fragment parts used in a substantially
similar context (defined by browser session cache rules) result in a
single request
3. HTML defines a subresource with @id that may be attached to <script>
4. XML defines a subresource with @xml:id that may be attached to any element
5. ESSL includes a lexical preprocessor with conditional blocks
6. Shader type is detectable from and required by already deployed analysis

Why not accept a URL for each pipeline component (vertex, fragment for
WebGLSL) and allow authors to refer to subresources? This gives
authors the freedom to use different URLs or supply a single effect
stage and does not require a specific XML package format unless
desired. This also gives each separate programmable pipeline stage a
unique name as a first-class resource.

Here are some simple uses:

1. Author writes script/@type="application/webglsl" with @id="curl" or
@id="my-effect-vs" in HTML and refers to it in later stylesheet or
from external stylesheet with fragment-identified page URL. Browser
sends "application/webglsl, text/html" for shader resource request (or
simply reads the loaded DOM if URL matches).
2. Author embeds shaders in any XML dialect that they want with
@xml:id. Browser sends "application/webglsl, application/xml" for
shader resource request.
3. FXTF proposes a WebGLSL fragment identifier syntax for a
to-be-registered WebGLSL media type that allows macros to be supplied.
For example: "pipeline-url#?D=VS&D=ITERATIONS=6" and
"pipeline-url#?D=FS". (-D for Define like command-line C
compilers/preprocessors) Shader authors then use normal (e.g. "#ifdef
FS") preprocessor directives in their (potentially combined) shaders.
4. FXTF defines a new XML or JSON package format with fragment
identification specified.

What use cases aren't covered by these identification methods? I think
each is valuable, simple, orthogonal, and relatively future-proof.
None precludes the others or unified XML effect formats. Each is
declarable in Accept headers. I would love to hear your thoughts on
this approach.

One pitfall that the flexible combination of these schemes creates is
the possibility of nesting subresources like
"xml-shader-pkg#cool-effect#?D=VS" which is, at present, not a valid
URI (too many "#" signs). I don't think this should stop
standardization of any or all of these methods, however. Authors
should simply be advised not to use both WebGLSL fragid macros and
subresource addresses simultaneously until sub-fragids are
standardized and deployed. WHATWG balked at decisively expanding the
identifier space to allow multiple "#" in a semantic way but IETF has
begun the next revision of STD-66 and may allow multiple "#" to
correct RFC 3986 errata 3330.

Sincerely,

David

Received on Monday, 3 December 2012 22:30:37 UTC