STEP ==== 1. Browse http://www.mizuao.com/javascriptbench/javascriptbench_koch_0.1.2.html 2. Click [start (Web Workers)] RESULT SCORE (small is fast) ============================ Firefox 4 Gecko/20100928 with D2D ... 18830 Chrome 7 ... 566 Opera 10.62 ... 27214

Curious. I'm seeing _much_ smaller numbers than that with a current trunk nightly (about 1400, whereas Chrome 7 dev is at about 1050). We're still about 30% slower than Chrome, but that seems to be due to us painting in the middle of all that message processing (the worker sends about 13000 messages). In particular, if I change the onmessage to just queue up the data and then paint all the paths to the canvas at once when I get "END", then I get about the same runtimes as Chrome. I'm not sure whether the paints should be interleaving with the messages here, and in any case once we switch paints to refresh driver that problem will go away. But the Windows behavior above indicates that there might be a graphics performance issue here....

Interestingly, if I load that testcase in my main browsing profile it seems to paint a pixel at a time instead of in chunks as it does in my test build. I have no idea why, but of course it takes longer.

Makoto Kato, were you seeing something like the behavior from comment 4?

On my nightly mac build I'm seeing a tremendously slowly paint. The resulting number is 203464 (!!), and this is on a pretty new MacBook Pro, so not a slow machine in any way. I definitely looks like what comment 4 describes, drawing one pixel at a time resulting in the fractal sort of "snaking" onto the screen. The above is when I press the "Start (web worker)" button. If I press the "Start (normal)" button the whole thing appears in a flash, giving me 225. With chrome I'm getting 1091 for web worker version and 228 for normal version.

Is this a graphics issue?

(In reply to comment #4) > Interestingly, if I load that testcase in my main browsing profile it seems to > paint a pixel at a time instead of in chunks as it does in my test build. That could be because your test build is built against the 10.6 SDK whereas the nightly build is built against the 10.5 SDK (at least before we switched to universal builds). 10.5 builds repaint after every iteration through the native event loop, 10.6 builds do it off a timer. (This is described on http://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKit.html under "NSWindow autodisplay behavior".) Bug 598482 will make us do the timer thing on 10.5, too.

Here are Mac and Windows builds from bug 598482: http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mstange@themasta.com-1cbfdd15ccc2/tryserver-macosx64/ http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mstange@themasta.com-5fdf456e1b51/tryserver-win32/ Makato Kato, does the Windows build speed up the testcase for you?

(In reply to comment #9) > Here are Mac and Windows builds from bug 598482: > http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mstange@themasta.com-1cbfdd15ccc2/tryserver-macosx64/ > http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mstange@themasta.com-5fdf456e1b51/tryserver-win32/ > > Makato Kato, does the Windows build speed up the testcase for you? Great!. Score becomes 800 by your try server build for win32.

The osx64 build is behaving very strange for me. Most of the time only part of the fractal is drawn, and then the page seems to "hang". It's still returning to the event loop, since you can easily reload or close the page, however the page itself seems to be in a state where it's not working correctly. Not sure if it's related to your changes or not though.

Oh, but yes, when it's working it's working great. Still draws the fractal in a few sections, not in one burst like in chrome, but the score is in the order of 1500-2000.

(In reply to comment #11) > however the > page itself seems to be in a state where it's not working correctly. I sometimes see it stop adding new fractal parts halfway through. Is that what you mean, or is it broken in more ways than that?

That's it

I just profiled this in a 64 bit os x build and it looks like we're spending all of our time on the main thread. Worker stuff barely registers. Almost everything is under nsLayoutUtils::PaintFrame, and under that we're spending 74% under mozilla::layers::CanvasLayerOGL::Updated.

On Windows 7, Firefox 10 (with D2D) beats Chrome 17: Firefox gets 1258 while Chrome gets 1479. On OS X, Chrome 17 gets 1055 while Firefox 11 gets 88519.

Now that bug 598482 is fixed I see this: Chrome: MAX: 552 MIN: 507 AVERAGE: 522 Firefox: MAX: 665 MIN: 620 AVERAGE: 637 Much closer, but we're still losing a little somehow.