Re: [css-shaders] Exploring JS shaders

JS can produce valid GLSL with no practical performance cost / overhead.
That's not true of a GLSL interpreter written in JS -- there is a cost.

The GLSL ecosystem (vendor drivers) has a lot of semantics that may mean 
a poor compile-time performance,
and a lot of driver-specific extensions / features. There are just 
-so-many- barriers to WebGL use.

We don't have that situation with an isolated JS thread, the only issue 
is speed.


-Charles

On 11/6/11 3:40 PM, Vincent Hardy wrote:
> Hi Charles,
>
> Thanks for the pointers.
>
> Since your examples show that there is technology to basically run a 
> GLSL shader in JS for other purposes, doesn't that mean selecting GLSL 
> for CSS shader is a good avenue, since the same shader could then be 
> interpreted in JS would people want to use it for something else?
>
> Kind regards,
> Vincent
>
> From: Charles Pritchard <chuck@jumis.com <mailto:chuck@jumis.com>>
> Date: Thu, 3 Nov 2011 23:49:18 -0700
> To: Adobe Systems <vhardy@adobe.com <mailto:vhardy@adobe.com>>
> Cc: "public-fx@w3.org <mailto:public-fx@w3.org>" <public-fx@w3.org 
> <mailto:public-fx@w3.org>>
> Subject: Re: [css-shaders] Exploring JS shaders
>
>     Here's an example someone wrote showing how Web Workers can be
>     used with bitmaps:
>     http://code.google.com/p/chromabrush/source/browse/frontend/js/filter.blur.js
>
>     That arguments and return would have to be tweaked a little, but
>     it shows the concept.
>     In practice, we'd want to transfer ArrayBuffer objects using the
>     structured clone algorithm.
>
>     For what it's worth, someone went and implemented a GLSL parser (a
>     whole WebGL implementation) in JS for Canvas 2d:
>     http://code.google.com/p/cwebgl/
>
>     CWebGL is from Cimaron Shanahan, MIT License.
>
>     The Chromabrush blur filter is from Arne Roomann-Kurrik, Apache
>     License 2.0
>
>     CWebGL demonstrates that JS can parse and run GLSL vector and
>     pixel shaders -- both the format and the function. The filter.blur
>     demonstration shows how we normally handle off-thread pixel
>     shaders in JS, for Canvas 2d.
>
>     The RiverTrail and W16 projects demonstrate that tight for loops
>     written in JS can be run over multiple (cpu) cores.
>
>
>     An Aside:
>
>     It'd be nice if we didn't -have- to have a GLSL filter and a JS
>     filter for everything we do... For performance, we have GLSL, for
>     compatibility (and flexibility) we have JS; we duplicate our
>     shaders. I've gone so far as to toy with HaXe (haxe.org) and its
>     macro features to write my shaders once and get source code spit
>     out for them in several languages.
>
>
>     -Charles
>
>
>     On 10/20/11 12:51 PM, Vincent Hardy wrote:
>>     Hi Charles,
>>
>>     I think this is an interesting. You are talking about exploring
>>     this idea: do you have an example of how you would go about
>>     writing a shader in this context?
>>
>>     Thanks,
>>     Vincent
>>
>>     From: Charles Pritchard <chuck@jumis.com <mailto:chuck@jumis.com>>
>>     Date: Thu, 20 Oct 2011 12:14:23 -0700
>>     To: "public-fx@w3.org <mailto:public-fx@w3.org>"
>>     <public-fx@w3.org <mailto:public-fx@w3.org>>
>>     Subject: [css-shaders] Exploring JS shaders
>>
>>         Carrying on from the [css-shaders] discussion on www-style,
>>         in which it
>>         has been proposed that webgl shaders
>>         be usable through the css filter() property...
>>
>>         CSS Shaders editorial draft:
>>         https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html
>>
>>
>>         I'd like to explore the use of JS as an additional route for
>>         authors to
>>         write shaders.
>>
>>         The Web Workers specifications and Transferable semantics (
>>         postMessage
>>         ) are reasonable mature, nowadays.
>>
>>         There are now two implementations for parallelism in tight
>>         JavaScript loops:
>>
>>         W16 for the V8 JS Engine:
>>         https://github.com/sheremetyev/w16
>>
>>         River Trail, a Firefox extension:
>>         https://github.com/RiverTrail/RiverTrail
>>
>>
>>         Web Workers is isolated and off-thread; the structured clone
>>         algorithm
>>         allows for transferring
>>         buffers across threads without needing to copy the buffer.
>>         The recent
>>         parallel extensions for Firefox and V8
>>         demonstrate that JS can be used across multiple cores, in an
>>         array
>>         programming style.
>>
>>         This seems like a natural progression.
>>
>>         Intel writing that River Trail can work well within existing
>>         semantics
>>         as well as Web GL:
>>         http://blogs.intel.com/research/2011/09/pjs.php
>>
>>
>>
>>         -Charles
>>
>>
>>
>>
>>
>>
>
>
>