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