[Public WebGL] WebGLSL Media Type Application

Florian Bösch [email protected]
Mon Dec 10 13:57:23 PST 2012

I'm mainly concerned keeping things efficient to transport. I don't think I
personally particularly care about what syntax/format transports a shader
since I'm gonna generate it anyway from my shader sources. I've heard that
there's some work in archive (tar, zip etc.) URLs, that would fit nicely

On Mon, Dec 10, 2012 at 10:38 PM, David Sheets <[email protected]> wrote:

> On Mon, Nov 19, 2012 at 5:09 AM, Florian Bösch <[email protected]> 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 <[email protected]>
> 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 [email protected]
> >> To unsubscribe, send an email to [email protected] with
> >> the following command in the body of your email:
> >> unsubscribe public_webgl
> >> -----------------------------------------------------------
> >>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20121210/a346f4fb/attachment.html>

More information about the public_webgl mailing list