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

[Jonas Sicking]

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

gets to be cheaper than

1. Drawing to on-screen canvas.

>> The other use case I can think of is doing image manipulation and then
>> sending the result directly to the server, without ever displaying it
>> to the user. However this is first of all not supported by the
>> suggested API, and second I can't think of any image manipulation that
>> you wouldn't want to display to the user except for scaling down a
>> high resolution image. But that seems like a much simpler API than all
>> of canvas. And again, not even this simple use case is supported by
>> the current API.
>
> OK, so you solve this one problem.  Then soon enough someone wants to do
> something more than just scale an image.  So you you add another one off
> solution.  Then another.  Next thing you've essentially created canvas
> prime....

We've always started with use cases and then created APIs that
fulfills those use cases, rather than come up with APIs and hope that
that fulfills some future use case. That seems like a much wiser path
here too.

> I'll note that there are a bunch of teams that want this behavior, though I
> can't remember exactly what for.

But you're sure that it fulfills their requirements? ;-)

> At least some of it is "simple" image
> resizing type stuff.  Most of it is related to doing image manipulation work
> that the app is probably going to need soon (but isn't on the screen
> yet...and that we don't want to slow the main thread for).
> Really, if you use picassa (or iPhoto or some other competitor) it really
> isn't hard to think of a lot of uses for this.  Even for non-photo Apps
> (like Bespin) I could totally see it being worth it to them to do some
> rendering off the main loop.

For many of these things you want to display the image to the user at
the same time as the

> To be honest, I think the applications are largely self evident...especially
> if you think about taking rich desktop apps and making them web apps.

So picassa and/or iPhoto uses off-main-thread *drawing* (not image
scaling) today?

>  Are
> you sure that you're negativity towards an offscreen canvas isn't simply
> being driven by implementation related worries?

Quite certain. I can promise to for every API suggested, that if there
are no use cases included, and no one else asks, I will ask what the
use case is.

/ Jonas