W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Re: [css-shaders] Exploring JS shaders

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 03 Nov 2011 23:49:18 -0700
Message-ID: <4EB38AEE.6090509@jumis.com>
To: Vincent Hardy <vhardy@adobe.com>
CC: "public-fx@w3.org" <public-fx@w3.org>
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
>
>
>
>
>
>
Received on Friday, 4 November 2011 07:10:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 4 November 2011 07:10:23 GMT