[whatwg] Offscreen canvas (or canvas for web workers).

[Jeremy Orlow]

On Tue, Feb 23, 2010 at 12:46 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Mon, Feb 22, 2010 at 4:34 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> > On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking <jonas at sicking.cc>
> wrote:
> >>
> >> On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow <jorlow at chromium.org>
> wrote:
> >> > On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking <jonas at sicking.cc>
> >> > wrote:
> >> >>
> >> >> On Mon, Feb 22, 2010 at 11:13 AM, David Levin <levin at google.com>
> wrote:
> >> >> > I've talked with some other folks on WebKit (Maciej and Oliver)
> about
> >> >> > having
> >> >> > a canvas that is available to workers. They suggested some nice
> >> >> > modifications to make it an offscreen canvas, which may be used in
> >> >> > the
> >> >> > Document or in a Worker.
> >> >>
> >> >> What is the use case for this? It seems like in most cases you'll
> want
> >> >> to display something on screen to the user, and so the difference
> >> >> comes down to shipping drawing commands across the pipe, vs. shipping
> >> >> the pixel data.
> >> >
> >> > Sometimes the commands take up a lot more CPU power than shipping the
> >> > pixels.  Lets say you wanted to have a really rich map application
> that
> >> > looked great, was highly interactive/fluid, but didn't use a lot of
> >> > bandwidth.  Rendering different parts of the screen on different
> workers
> >> > seems like a legit use.
> >>
> >> I admit to not being a graphics expert, but I would imagine you have
> >> to do quite a lot of drawing before
> >> 1. Drawing on offscreen canvas
> >> 2. Cloning the pixel data in order to ship it to a different thread
> >> 3. Drawing the pixel data to the on-screen canvas
> >
> > Presumably a smart UA implementation could make 1 and 3 be nearly nothing
> > (with copy on write and such) in many cases.
>
> Huh? I thought the whole point was that 1 was expensive, which was why
> you wanted to do it off the main thread.
>
> And 3 is what puts pixels on the screen so I don't see how you could
> do that without copying. You could possibly implement 3 using
> blitting, but that's still not "nearly nothing".
>
> Possibly 2 is what you could get rid of using copy-on-write.
>
> >> gets to be cheaper than
> >>
> >> 1. Drawing to on-screen canvas.
> >
> > You're assuming only one core.  The norm on the desktops and laptops
> these
> > days is multiple cores.
>
> I did not assume that no. But it sounded like your use case was to
> rasterize off the main thread, get the pixels to the main thread, and
> then draw there. The last part (step 3 above) will definitely happen
> on the main thread no matter how many cores you have.
>

Sorry, I didn't read clearly before sending.

Yes, 1 would presumably be expensive and thus worth doing on a worker.  Even
on a single core machine, workers are great for long tasks since you needn't
add breaks to your code via setTimeout so the UI can be updated (which
doesn't always work perfectly anyway).

2 could be done with copy on write in many cases.  3 is just blitting which
is generally a pretty fast operation.


I've gotten a couple responses back on use cases.  I'll admit that about
half a simply resize/rotate.  The others I've been told I cannot talk about
publicly.  I think my map tiles example is similar enough to a bunch of them
though that you can get at least the conceptual idea.  And my understanding
is that in prototypes, it's been very hard to do the (computationally
complex) rendering without making the UI go janky.  There might be some more
use cases that come up that I can generalize into a public form, in which
case I'll do my best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100223/7f1fb0c4/attachment-0002.htm>