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

[Darin Fisher]

On Mon, Feb 22, 2010 at 4:05 PM, 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
>
>
The pixel copies are not as expensive as you might imagine.  (You just
described how rendering works in Chrome.)  Step #1 can vastly dominate if
drawing is complex.

Imagine if it involved something as complicated and expensive as rendering a
web page.  Doing work that expensive on a background thread becomes
imperative to maintaining good responsiveness of the main UI thread of the
application, so the extra copies can be well worth the cost.

-Darin




> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100223/0dd64957/attachment-0002.htm>