On Tue, Feb 23, 2010 at 12:46 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><div></div><div class="h5">On Mon, Feb 22, 2010 at 4:34 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking <jonas@sicking.cc> wrote:<br>
>><br>
>> 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><br>
>> > 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<br>
>> >> > 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>
>> 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>
> Presumably a smart UA implementation could make 1 and 3 be nearly nothing<br>
> (with copy on write and such) in many cases.<br>
<br>
</div></div>Huh? I thought the whole point was that 1 was expensive, which was why<br>
you wanted to do it off the main thread.<br>
<br>
And 3 is what puts pixels on the screen so I don't see how you could<br>
do that without copying. You could possibly implement 3 using<br>
blitting, but that's still not "nearly nothing".<br>
<br>
Possibly 2 is what you could get rid of using copy-on-write.<br>
<div class="im"><br>
>> gets to be cheaper than<br>
>><br>
>> 1. Drawing to on-screen canvas.<br>
><br>
> You're assuming only one core.  The norm on the desktops and laptops these<br>
> days is multiple cores.<br>
<br>
</div>I did not assume that no. But it sounded like your use case was to<br>
rasterize off the main thread, get the pixels to the main thread, and<br>
then draw there. The last part (step 3 above) will definitely happen<br>
on the main thread no matter how many cores you have.<br></blockquote><div><br></div><div>Sorry, I didn't read clearly before sending.</div><div><br></div><div>Yes, 1 would presumably be expensive and thus worth doing on a worker.  Even on a single core machine, workers are great for long tasks since you needn't add breaks to your code via setTimeout so the UI can be updated (which doesn't always work perfectly anyway).</div>

<div><br></div><div>2 could be done with copy on write in many cases.  3 is just blitting which is generally a pretty fast operation.</div><div><br></div><div><br></div><div>I've gotten a couple responses back on use cases.  I'll admit that about half a simply resize/rotate.  The others I've been told I cannot talk about publicly.  I think my map tiles example is similar enough to a bunch of them though that you can get at least the conceptual idea.  And my understanding is that in prototypes, it's been very hard to do the (computationally complex) rendering without making the UI go janky.  There might be some more use cases that come up that I can generalize into a public form, in which case I'll do my best.</div>

</div>