- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 14 May 2012 18:32:55 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Glenn Maynard <glenn@zewt.org>, Anne van Kesteren <annevk@annevk.nl>, "Gregg Tavares (勤)" <gman@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
On 5/14/2012 6:23 PM, Jonas Sicking wrote: >>>> >>> This would also require some >>>> >>> equivalent to requestAnimationFrame in the worker thread. >>> >> >>> >> Agreed! >>> >> >>> >> / Jonas >> > >> > >> > >> > I'm a bit lost-- wouldn't we just postMessage from the document over to the web worker when we want a refresh? >> > >> > I agree that we ought to be transferring pixel data not Canvas contexts; with the possible exception of CSS context. >> > >> > We could just create new canvas instances inside the worker thread. I'd still prefer to clone CanvasPattern as a means of transferring paint over to the worker, though sending pixel data would work too. >> > >> > I heard Picture come up-- it seems like that object might have additional semantics for high resolution alternatives that may need to be considered. > I was saying that I think we should transfer the context from the main > thread to the worker thread. The worker thread should then be able to > use the context to draw directly to the screen without interacting > with the main thread. > > You should generally not need to transfer pixel data. But I think it > should be possible to grab pixel data on whichever thread is currently > owning a context. This will implicitly make it possible to transfer > pixel data if anyone wants to do it. OK, that's the same concept as I was hoping for with document.getCSSCanvasContext. Mozilla is a bit ahead of webkit, going with "element(any-element)" -- webkit has "-webkit-canvas(css-canvas-id)". It's a very different approach. I'd still go ahead and just have requestAnimationFrame pump events from the main frame. There are so many things that could block the main frame to where an rAF repaint just isn't necessary from the worker-end. It may also keep some animations continuing. I'm not positive, but something like window.prompt may block execution on the main thread, but if rAF were running on the worker, its repaints would still happen. Generally, while the main thread is blocked, repainting on it is not going to be that useful; we're shuffling the repaints off so they aren't the cause of blocking. Those are the two sides of it that I see... but it's still a very different proposal than the idea of just having non-transferable canvas contexts. ... Boris brought up some good points about possible blocking in implementations with loading SVG images in the worker thread via Picture (or a chopped down Image). At present, those sound more like implementation-issues, not particularly issues in the validity of a spec. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0744.html They do sound a little unfortunate, but I'd sooner trade some possible blocking between a Worker and the main thread, than having to carry a full SVG parser written in JS in my worker threads. As an author, I've always had to take precautions for SVG and decide whether I want to render or give myself up to the browser implementation. -Charles
Received on Tuesday, 15 May 2012 01:33:21 UTC