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

Re: [css4-images] custom blending effects

From: Dean Jackson <dino@apple.com>
Date: Mon, 28 Nov 2011 14:36:43 +1100
Message-id: <15EA84AB-D3D7-45B0-A40F-6FEC789E67BC@apple.com>
Cc: Rik Cabanier <cabanier@gmail.com>, www-style list <www-style@w3.org>
To: Charles Pritchard <chuck@jumis.com>
I think I misunderstood. I thought you were suggesting a JS-based image processing language instead of GLSL (or something that compiled to GLSL)

Dean

On 28/11/2011, at 7:13, Charles Pritchard <chuck@jumis.com> wrote:

> 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 Monday, 28 November 2011 03:37:31 GMT

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