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

On Dec 3, 2012, at 2:30 PM, David Sheets <kosmo.zb@gmail.com> wrote:

> 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)).

Dependent on the file format, it might not be necessary to rely on the MIME type. MIME types can also be a burden if the server does not support certain MIME types. The string for the format would be to determined. Any format needs to make sure that the requirements of the used language are fulfilled.

> 
>> 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.

Ideally the package format should be determined by the string passed to the 'format()' function.

> 
>> 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.

If we chose an XML file as manifest file, the proposed <fragment> and <vertex> elements can use xlink:href to reference external shader files:

<fragment xlink:href="fragmentShader.fs"/>

Is it that what you mean?

An XML file seems to be easier to support by browsers, since browsers already have a way to parse XML documents. This would avoid defining a parser for the description document. But we would indeed meet to define a schema for the XML file.

At this point we didn't thought about the details of the file format, since we would like to agree on the CSS syntax first.


> 
> 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.

I am not sure if I got your point correctly. But the general Idea of the CSS WG is to separate styling from the content. That is why we try to void to bundle the style sheet to much to the document using it.

> 
> 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.

I think an example would make it easier to understand your proposal.

> 
> 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

Greetings,
Dirk

Received on Monday, 3 December 2012 23:46:44 UTC