On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><div class="gmail_quote"><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></blockquote><div><br></div><div>Presumably a smart UA implementation could make 1 and 3 be nearly nothing (with copy on write and such) in many cases.</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></blockquote><div><br></div><div>You're assuming only one core. The norm on the desktops and laptops these days is multiple cores. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
>> 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></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> 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></blockquote><div><br></div><div>I don't know. But you're probably right that scaling (and rotating) is probably the bulk of what is computationally expensive.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> 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></blockquote><div><br></div><div>Fair enough.</div></div>