[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGLSL Media Type Application



On Mon, Nov 19, 2012 at 5:09 AM, Florian Bösch <pyalot@gmail.com> wrote:
> You're ignoring transport at your own and that of everbody who wants to
> write CSS shaders at your own peril (for reference, google for css icon
> fonts and css sprite sheets load optimization techniques).

Florian,

The CSS/SVG FXTF is presently deliberating on the appropriate method
to incorporate transport into the Filter Effects 1.0 specification.
The two primary proposals at the moment are:

1. Use the extensibility features of the platform (fragment
identifiers (HTML @id, xml:id), media types, CSS @import and media
queries) with CSS filter-model specific properties defined in a new
flavor of CSS at-rule. This was first proposed by Dirk Schulze
<http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0029.html>
and later revised by me to smooth syntax and integrate more tightly
with other standards' extensibility features
<http://dsheets.github.com/custom-fx-modules/>.

2. Require Filter Effects users to create an XML resource using a
specific Filter Effects XML vocabulary to define pairs of
vertex/fragment shaders. This was first proposed by Dirk Schulze
<http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0054.html>
and seems to be the presently favored approach.

My question to you:

Do you want to generate XML, base64 encode it, and stuff it in a data:
URL to dynamically load custom CSS filters?

If so, FXTF may have a solution for you!

If you'd rather handle the transport format in a way that best fits
your app and not have to muck about with generating XML, perhaps you
would like to support generic resource references so that you may
refer to any format that supports a fragment identifier syntax and use
the CSS JS API to set custom filter parameters. Feel free to post to
public-fx with your thoughts.

As you can see, the specific transport format and the means to
request, transmit, and refer to secondary resources in that format are
orthogonal. Khronos should promulgate a good media type for WebGLSL. I
suggest "application/webglsl" with an optional version parameter that
accepts an integer and indicates understanding of versions UP TO AND
INCLUDING that version for requests and AT LEAST that version for
tags/responses. If this optional parameter makes your head hurt, feel
free to drop it.

What do you think? Do you want a mandatory XML CSS shader transport?
When is the right time for Khronos to specify a media type for the
shading language in general?

Regards,

David

> On Mon, Nov 19, 2012 at 3:00 AM, David Sheets <kosmo.zb@gmail.com> wrote:
>>
>>
>> Hello, world!
>>
>> You might be interested in a recent proposal
>> <http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0029.html>
>> by Adobe to the CSS FX TF concerning multiple shader languages.
>>
>> In this use case, shader source resources are identified by URL in CSS
>> "@ rules".
>>
>> What media type should be used for these URL dereferences? Do you want
>> to pay for multiple HTTP requests for equivalent content? I sent an
>> analysis
>> <http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0049.html>
>> to the public-fx list which attempts to answer questions like these.
>>
>> Please, keep this thread on-topic regarding the specific issue of a
>> WebGLSL media type. Specifically, this thread is not to discuss the
>> merits or problems with specific approaches to embed or load shader
>> source. People seemed particularly pre-occupied with this topic the
>> last time this issue was raised (6 months ago) and it is absolutely
>> irrelevant to the matter at hand as the CSS application demonstrates.
>> Let us instead discuss the standard naming of the shading language and
>> related aspects.
>>
>> Looking forward to your ideas,
>>
>> David Sheets
>>
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------