W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: [css4-images] custom blending effects

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 27 Nov 2011 12:13:44 -0800
Message-ID: <4ED299F8.5030106@jumis.com>
To: Dean Jackson <dino@apple.com>
CC: Rik Cabanier <cabanier@gmail.com>, www-style list <www-style@w3.org>
On 11/27/11 10:56 AM, Dean Jackson wrote:
>
> On 27/11/2011, at 3:58 PM, Charles Pritchard wrote:
>
>> I've proposed JS shaders in addition to glsl.
>
> There are a few things against JS shaders:

I don't believe these are arguments "against" JS shaders.

> - The GLSL horse has already bolted. It's part of WebGL.

JS image manipulation is part of Canvas 2d.

> - There is a huge amount of content already out there using GLSL (both 
> on and off the Web).

Mostly off the web. There is a large amount of content already out there 
for JS as well.

> - Many many tools support it.

GLSL has varying results on even the latest browser builds because of 
hardware dependencies.

> - There are many things we'd need to add to the JS language in order 
> to map to GPU types.

We don't need to map GPU types. It might be nice, though, to do that 
some time.

> - Unless people completely understand the conversion to the native 
> shading language, then debugging and performance tuning could be 
> difficult.

I don't understand this point.

>
> There are a few things for it too:
>
> - It might be more acceptable to those platforms (platform?) that 
> don't have GLSL by default, assuming JSS can be easily converted to 
> GLSL or HLSL.

It's not necessary to run JS on the GPU. If that were the goal, then an 
API would be the easier route on everyone, with the typical GPU-types 
and math.
At that point, the target might expand beyond GLSL to include 
OpenCL-like semantics.

> - It's JavaScript, which many developers will be familiar with (on the 
> downside, it won't necessarily look like regular JS).

I'm just proposing doing what's already there on the web with 
CanvasPixelArray.
For typed JavaScript, you might look at Intel's River Trail experiment.
> - It might better enable a software rendering mode
>
> I think we need a concrete proposal otherwise this is stuck in the 
> "wouldn't it be nice" box.

I'm trying to clear up scope, and misunderstandings early on. I'm happy 
to work on a more concrete proposal.

I do appreciate you responding so promptly and thoroughly.

My proposal is to use a minimal Web Worker scope (so the data remains 
opaque to the author) and the typical 32-bit-per-pixel CanvasPixelArray 
semantics, referencing the typed array spec.

This would allow authors to easily re-use their existing 
CanvasPixelArray loops. Authors are already encouraged to separate them 
into individual JS files and run them within web workers.

The W16 (a branch of the V8 code base) project has shown that tight 
loops can be run across multiple CPU cores.
Received on Sunday, 27 November 2011 20:14:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT