- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Fri, 11 Dec 2009 02:30:23 -0800
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>
Received on Friday, 11 December 2009 02:30:23 UTC