[whatwg] Offscreen canvas (or canvas for web workers).
jorlow at chromium.org
Mon Feb 22 16:34:44 PST 2010
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>
> >> 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
> > 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
> > 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg