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

[Jeremy Orlow]

On Tue, Feb 23, 2010 at 11:31 AM, Jeremy Orlow <jorlow at chromium.org> wrote:

> 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.
>

Note that doing rendering in a worker and then displaying it on the the main
thread also gives you double buffering for no additional cost.  This is
something our teams are excited about as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100223/8db7dce5/attachment-0002.htm>