- From: Dean Jackson <dino@apple.com>
- Date: Mon, 28 Nov 2011 14:36:43 +1100
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, www-style list <www-style@w3.org>
- Message-id: <15EA84AB-D3D7-45B0-A40F-6FEC789E67BC@apple.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 UTC