637874 - Chrome does 2.5x more mutations per second on image evolution

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[David Mandelin [:dmandelin]]

See the linked URL. Firefox does 60 mutations per second, Chrome 155. I strongly suspect this is because of the 10ms min on setTimeout delays (that corresponds to 60 Hz, and Chrome uses 4ms, which corresponds to 150Hz).

Comment 1

[Boris Zbarsky [:bzbarsky]]

I see 117 mutations per second in Chrome 11, and 78 in my current m-c opt build.

If I change the "dom.min_timeout_value" preference to 4, so that our clamp on timeouts is only 4ms, I see about 80 mutations per second.  So not much better....

Also note that while the 10ms thing will definitely keep us from going over 100Hz, the fact that we aren't even reaching 100Hz tells us we're CPU-bound.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Profile on Mac says:

  19% painting
   8% mac event loop and paint stuff overhead
  17% tracejit-generated code
  46% under fill() on a canvas
   2% getImageData on a canvas
   3% setting style on canvas
   1% js::mjit::stubs::add (adding non-strings to strings?)
   1% mjit-generated code
   2% fillRect, lineTo, moveTo, beginPath, closePath on canvas

There's no DOM anywhere here, really.  Graphics and JS all the way, mostly graphics.  ;)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Note that the numbers above may look very different on Windows with d2d...

Comment 4

[Asa Dotzler [:asa]]

On Windows with D2D, Chrome is just over twice as fast.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Paging Bas!

Comment 6

[Asa Dotzler [:asa]]

More data: 

On my Win 7 machine with D2D Chrome is actually 3.2x faster than Firefox. On my Win XP machine without D2D Chrome is 2.1x faster. So, D2D doesn't seem to help at all here.

Comment 7

[David Mandelin [:dmandelin]]

(In reply to comment #6)
> More data: 
> 
> On my Win 7 machine with D2D Chrome is actually 3.2x faster than Firefox. On
> my Win XP machine without D2D Chrome is 2.1x faster. So, D2D doesn't seem to
> help at all here.

I'm pretty sure bz has most of it comment 1: Chrome has a smaller minimum timeout.

Comment 8

[Boris Zbarsky [:bzbarsky]]

No.  It doesn't.  Our minimum timeout matches theirs at this point, changing the timeout to match theirs back then didn't change our numbers at all, and our number was way lower than if it were gated on the minimum timeout.  This is a pure performance "we're using too much CPU" bug.

Comment 9

[Bas Schouten (:bas.schouten)]

The problem here is most likely getImageData. GetImageData is particularly hard for any hardware accelerated system because it will have to block on the GPU completing any commands in the pipeline in order to readback. Doing this many times a second causes serious performance issues.

There's no 'easy' solution here, a possibility is trying to detect situations where getImageData is used a lot, and fall back to software there. But such heuristics are tricky. On larger images we should be doing a lot better since the situation will become more fillrate bound where the GPU actually gives us a win. Part of the problem here is that due to the tiny image the GPU simply isn't doing a lot for us either in this situation.

Comment 10

[Bas Schouten (:bas.schouten)]

Oh, I should note IE9 does a lot worse than us. But the IE10 platform preview does slightly better. I'm unsure at this point what IE10 does for getImageData, but it is possible they implement such heuristics as described, or found another way to improve the situation.

If I were to solve this in C++ I'd create one thread which fires the mutations to the GPU, and one which waits for data readback to have finished on each frame and performs the analysis, if the GPU gets too far ahead of the analysis thread, it waits, but the analysis thread would generally not have to wait after receiving its first readback.

Of course I don't how such an asynchronous readback technique could be applied to this demo.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Would the readback situation apply to Mac too?  Or is that something else?  Generally getImageData has been fast on Mac...

Comment 12

[Benoit Girard (:BenWa)]

I get 80 on Aurora 9.0a2 vs. 150 on Chrome on Mac.

Comment 13

[Eric Sh.]

On windows XP I get 45(with HWA) and 50(without HWA) and on chrome I get about 60.

Comment 14

[Ali Juma [:ajuma]]

On Mac, I get 135 on Nightly vs. 200 on Chrome on Lion, on the same hardware as BenWa (who's on Snow Leopard).

On Win 7, I get 68 on Nightly vs. 20 on Chrome.

Comment 15

[Benoit Girard (:BenWa)]

I get 180 mutations when viewed on my external monitor and 60 when viewed on my laptop monitor. We might be hitting some form of vsync here, at least on some cases.

Comment 16

[Benoit Girard (:BenWa)]

Attachment: Non frame limited variant

I made a variant of the page above to work with a display-none canvas and update the results every 800 ms or when a new best match is found (you can change the timeout in javascript).

This decouples the execution speed from our frame rate.

With this simple change I get from 60 to 200 iterations on Firefox and 180 on Chrome Canary (run with --allow-file-access-from-files to allow cross origin canvas readback).

I think we should close this as INVALID. Can someone verify this on windows with my test?

Comment 17

[Benoit Girard (:BenWa)]

With some optimization of setInterval to push mutations above 220+/second we become limited by garbage collection.