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

[Jeremy Orlow]

On Fri, Dec 11, 2009 at 12:49 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Thu, Dec 10, 2009 at 1:36 PM, 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'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);
>
> Do you really need all of CanvasRenderingContext2D? I.e. do you really
> need things like spline drawing, pattern filling, and text?
>
> My concern weather the libraries backing CanvasRenderingContext2D are
> generally threadsafe?
>

CanvasRenderingContext2Ds would never need to be shared between threads
because they're "cloned" when passed...so is your concern that the libraries
are only meant to ever be used from one thread?  Maybe I'm being naive, but
it would surprise me if that turned out to be an issue.


> The use case brought up at the beginning of this thread was about
> scaling. It would be dramatically easier to implement just a few
> things like transformations, cropping and encoding/decoding, than to
> implement all of CanvasRenderingContext2D off the main thread.
>

Resizing images was just one use.  I could easily imagine apps wanting to
generate more complex images on background threads without needing to
implement things like spline drawing, pattern filling, and text themselves.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091211/20ad9f98/attachment.htm>