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

[Jonas Sicking]

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.

/ Jonas