Re: [css-shaders] Exploring JS shaders

Hi Charles,

I think your idea of using a specialized WebWorker to implement a shading algorithm is definitely interesting and I have captured that in our Bugzilla issues for the spec:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14766

I think it would be great to have a specific proposal on how that might look and I would be happy to explore this with you.

Kind regards,
Vincent

From: Charles Pritchard <chuck@jumis.com<mailto:chuck@jumis.com>>
Date: Sun, 6 Nov 2011 15:56:31 -0800
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

Emscripten enables authors to write in a variety of languages such as C and C++, authors can even compile interpreters such as CPython.

It proves that JS related software has become quite fast and powerful over the years. That's what I intended to highlight. It's still a lot of overhead and a bit slower to have cross-language abstractions and interpreters.

In practical use, I'm still going to have pure JS shaders. I may produce some subset of my shader collection in a language like hAxe which supports readable JS output (to tweak and include as pure JS) in addition to optimized pixelbender kernels and C++ source code.

The Workers postMessage ArrayBuffer technique is in browsers currently, introduced by the WebGL group.



On Nov 6, 2011, at 3:40 PM, Vincent Hardy <vhardy@adobe.com<mailto:vhardy@adobe.com>> 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 <<mailto:chuck@jumis.com>chuck@jumis.com<mailto:chuck@jumis.com>>
Date: Thu, 3 Nov 2011 23:49:18 -0700
To: Adobe Systems <<mailto:vhardy@adobe.com>vhardy@adobe.com<mailto:vhardy@adobe.com>>
Cc: "<mailto:public-fx@w3.org>public-fx@w3.org<mailto: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>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/> 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<http://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 <<mailto:chuck@jumis.com>chuck@jumis.com<mailto:chuck@jumis.com>>
Date: Thu, 20 Oct 2011 12:14:23 -0700
To: "<mailto:public-fx@w3.org>public-fx@w3.org<mailto: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>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>https://github.com/sheremetyev/w16

River Trail, a Firefox extension:
<https://github.com/RiverTrail/RiverTrail>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>http://blogs.intel.com/research/2011/09/pjs.php



-Charles