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

Hi FXTF,

After some feedback and mails, my team and I looked through the mailing list and tried to clean-up our previous proposal and make it future proof.

In fact, new technologies can have a lot of different requirements. And we need to make sure that Filter Effects is ready for new features and future versions of WebGL as well as alternatives like HLSL.

One inspiration of our new proposal is based on ideas of Dean Jackson and Lea[1]. Lea suggested a @filter rule for the filter property. We really liked the idea and tried to combine the idea with shaders and come up with the following simple syntax:

	@filter IDENT {
		src: [ <uri> [format(<string>)]? ]#
		parameters: <param>
	}

And the filter function 'custom' with the syntax 

	custom(IDENT [, <params>]*) 

	<params> := as it is in the current spec.

That is the whole CSS syntax. Nothing more needed. Here a short example:

	@filter page-curl {
		src: url(shader.ext) format("glsl");
		parameters: curlDirection 90, curlAmount 0.5;
	}

	div {
		filter: blur(2px) custom(page-curl, curlAmount 0);
	}


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

-parameters descriptor
The parameter descriptor is as in our previous proposal. You can pass various parameters into the shader. For animation, parameters can be specified in the custom filter function. Definitions in the at-rule get overridden.


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.

Greetings,
Dirk

[1] http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0105.html

Received on Friday, 30 November 2012 18:49:24 UTC