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

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.


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

 >> 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've pinged a couple people within Google to see if we can re-gather what
some of the original use cases were.  I'll admit that resizing and rotating
were definitely at the top of the list, but I believe vector based drawing
was there too.  Will report back on this when I have more data.


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

I don't know.  But you're probably right that scaling (and rotating) is
probably the bulk of what is computationally expensive.


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

Fair enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100223/b0e7ae9e/attachment.htm>

Received on Monday, 22 February 2010 16:34:44 UTC