- From: Vincent Hardy <vhardy@adobe.com>
- Date: Thu, 20 Oct 2011 12:51:14 -0700
- To: Charles Pritchard <chuck@jumis.com>, "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CAC5F3C3.1D869%vhardy@adobe.com>
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 Thursday, 20 October 2011 19:51:47 UTC