<div class="gmail_quote">On Mon, Feb 22, 2010 at 4:05 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking <jonas@sicking.cc> wrote:<br>
>><br>
>> On Mon, Feb 22, 2010 at 11:13 AM, David Levin <<a href="mailto:levin@google.com">levin@google.com</a>> wrote:<br>
>> > I've talked with some other folks on WebKit (Maciej and Oliver) about<br>
>> > having<br>
>> > a canvas that is available to workers. They suggested some nice<br>
>> > modifications to make it an offscreen canvas, which may be used in the<br>
>> > Document or in a Worker.<br>
>><br>
>> What is the use case for this? It seems like in most cases you'll want<br>
>> to display something on screen to the user, and so the difference<br>
>> comes down to shipping drawing commands across the pipe, vs. shipping<br>
>> the pixel data.<br>
><br>
> Sometimes the commands take up a lot more CPU power than shipping the<br>
> pixels.  Lets say you wanted to have a really rich map application that<br>
> looked great, was highly interactive/fluid, but didn't use a lot of<br>
> bandwidth.  Rendering different parts of the screen on different workers<br>
> seems like a legit use.<br>
<br>
</div>I admit to not being a graphics expert, but I would imagine you have<br>
to do quite a lot of drawing before<br>
1. Drawing on offscreen canvas<br>
2. Cloning the pixel data in order to ship it to a different thread<br>
3. Drawing the pixel data to the on-screen canvas<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div>
<div>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.</div>
<div><br></div><div>-Darin</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
gets to be cheaper than<br>
<br>
1. Drawing to on-screen canvas.<br>
<div class="im"><br>
>> The other use case I can think of is doing image manipulation and then<br>
>> sending the result directly to the server, without ever displaying it<br>
>> to the user. However this is first of all not supported by the<br>
>> suggested API, and second I can't think of any image manipulation that<br>
>> you wouldn't want to display to the user except for scaling down a<br>
>> high resolution image. But that seems like a much simpler API than all<br>
>> of canvas. And again, not even this simple use case is supported by<br>
>> the current API.<br>
><br>
> OK, so you solve this one problem.  Then soon enough someone wants to do<br>
> something more than just scale an image.  So you you add another one off<br>
> solution.  Then another.  Next thing you've essentially created canvas<br>
> prime....<br>
<br>
</div>We've always started with use cases and then created APIs that<br>
fulfills those use cases, rather than come up with APIs and hope that<br>
that fulfills some future use case. That seems like a much wiser path<br>
here too.<br>
<div class="im"><br>
> I'll note that there are a bunch of teams that want this behavior, though I<br>
> can't remember exactly what for.<br>
<br>
</div>But you're sure that it fulfills their requirements? ;-)<br>
<div class="im"><br>
> At least some of it is "simple" image<br>
> resizing type stuff.  Most of it is related to doing image manipulation work<br>
> that the app is probably going to need soon (but isn't on the screen<br>
> yet...and that we don't want to slow the main thread for).<br>
> Really, if you use picassa (or iPhoto or some other competitor) it really<br>
> isn't hard to think of a lot of uses for this.  Even for non-photo Apps<br>
> (like Bespin) I could totally see it being worth it to them to do some<br>
> rendering off the main loop.<br>
<br>
</div>For many of these things you want to display the image to the user at<br>
the same time as the<br>
<div class="im"><br>
> To be honest, I think the applications are largely self evident...especially<br>
> if you think about taking rich desktop apps and making them web apps.<br>
<br>
</div>So picassa and/or iPhoto uses off-main-thread *drawing* (not image<br>
scaling) today?<br>
<div class="im"><br>
>  Are<br>
> you sure that you're negativity towards an offscreen canvas isn't simply<br>
> being driven by implementation related worries?<br>
<br>
</div>Quite certain. I can promise to for every API suggested, that if there<br>
are no use cases included, and no one else asks, I will ask what the<br>
use case is.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br>