- From: Oliver Hunt <oliver@apple.com>
- Date: Mon, 16 Apr 2012 14:57:26 -0700
On Apr 16, 2012, at 2:34 PM, Darin Fisher <darin at chromium.org> wrote:
> On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt <oliver at apple.com> wrote:
>
>>
>> On Apr 16, 2012, at 1:12 PM, Darin Fisher <darin at chromium.org> wrote:
>>
>> Glenn summarizes my concerns exactly. Deferred rendering is indeed the
>> more precise issue.
>>
>> On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt <oliver at apple.com> wrote:
>>
>>> Could someone construct a demonstration of where the read back of the
>>> imagedata takes longer than a runloop cycle?
>>>
>>
>> I bet this would be fairly easy to demonstrate.
>>
>>
>> Then by all means do :D
>>
>
>
> Here's an example.
>
> Take http://ie.microsoft.com/testdrive/Performance/FishIETank/, and apply
> the following diff (changing the draw function):
>
> BEGIN DIFF
> --- fishie.htm.orig 2012-04-16 14:23:29.224864338 -0700
> +++ fishie.htm 2012-04-16 14:21:38.115489276 -0700
> @@ -177,10 +177,17 @@
> // Draw each fish
> for (var fishie in fish) {
> fish[fishie].swim();
> }
>
> +
> + if (window.read_back) {
> + var data = ctx.getImageData(0, 0, WIDTH, HEIGHT).data;
> + var x = data[0]; // force readback
> + }
> +
> +
> //draw fpsometer with the current number of fish
> fpsMeter.Draw(fish.length);
> }
>
> function Fish() {
> END DIFF
>
> Running on a Mac Pro, with Chrome 19 (WebKit @r111385), with 1000 fish, I
> get 60 FPS. Setting read_back to true (using dev tools), drops it down to
> 30 FPS.
>
> Using about:tracing (a tool built into Chrome), I can see that the read
> pixels call is taking ~15 milliseconds to complete. The implied GL flush
> takes ~11 milliseconds.
>
> The page was sized to 1400 x 1000 pixels.
How does that compare to going through the runloop -- how long does it take to get from that point to a timeout being called if you do var start = new Date; setTimeout(function() {console.log(new Date - start);}, 0);
?
This also ignores that possibility that in requesting the data, i probably also want to do some processing on the data, so for the sake of simplicity how long does it take to subsequently iterate through every pixel and set it to 0?
Remember the goal of making this asynchronous is to improve performance, so the 11ms of drawing does have to occur at some point, you're just hoping that by making things asynchronous you can mask that. But I doubt you would see an actual improvement in wall clock performance.
I also realised something else that I had not previously considered -- if you're doing bitblit based sprite movement the complexity goes way up if this is asynchronous.
--Oliver
Received on Monday, 16 April 2012 14:57:26 UTC