W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] "offscreen canvas" /Access to canvas functionality from a worker

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 11 Dec 2009 08:53:55 +0100
Message-ID: <op.u4rj75yo64w2qv@anne-van-kesterens-macbook.local>
On Thu, 10 Dec 2009 22:36:45 +0100, Oliver Hunt <oliver at apple.com> wrote:
> Ideally if we were to have a graphics context in a worker we'd want it  
> to be the standard CanvasRenderingContext2D, the only real problem is  
> that CanvasRenderingContext2D references the parent canvas element which  
> clearly won't fly in a worker.

I think the solution to that is to just as with Navigator be more creative  
with IDL interfaces. The methods that take HTMLImageElement or  
HTMLVideoElement similarly should be excluded from the  
CanvasRenderingContext2D exposed within Web Workers.


> I've been thinking of creating something like a WorkerCanvas which is  
> basically a DOM-less CanvasRenderingContext2D, so you can do
>
> var canvas = new WorkerCanvas(width, height);
> canvas.putImageData(myData);

Something like that sounds good, though shouldn't putImageData() be on the  
2D context you can get via WorkerCanvas?


> I have a vague desire to allow a ImageData to be provided as a backing  
> store, but then you may hit perf or consistency issues on UAs that use  
> premultiplied alpha backing stores.
>
> Additionally there's the question of origin tainting -- is it possible  
> to taint the origin in a worker? you don;t have image elements, you  
> can't xhr unsafely to other origins, but maybe i'm missing something?

<canvas> can only be tainted by unsafe <img> or <video> elements. Neither  
is applicable, so no.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Thursday, 10 December 2009 23:53:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:54 UTC