User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20101026 Firefox/3.6.12 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101031 Firefox/4.0b8pre In tests 2, 3, and 4 of peacekeeper, it builds a grid of divs and then just changes the style.backgroundColor of each div. The difference between each test is just the number of divs, with test 2 having very few and test 4 having a lot. You can run test 4 at http://www.peacekeeper.therichins.net/test3b.html. On my Windows XP box, I get the following numbers: FF4: 5.069 Chrome7: 12.172 I tested it with "layers.accelerate-none" set to true and "layers.accelerate-all" set to false as well and the FPS was: FF4: 5.302 The line that is the major bottleneck is: this.pixels[y][x].style.backgroundColor = this.hex(c, Math.round(c / 2), 0); I've tried all the following changes and each one caused FF4 to be faster than Chrome. 1 - Commented out the line 2 - this.pixels[y][x] = this.hex(c, Math.round(c / 2), 0); 3 - this.pixels[y][x].style.backgroundColor = '#000000'; 4 - this.pixels.style.backgroundColor = this.hex(c, Math.round(c / 2), 0); I also tested with different number of divs. Around 169 divs (13x13) is when FF4 becomes slower than Chrome. I found bug 147796 which looks to be similar to this, but it dealt specifically with Linux. Reproducible: Always Steps to Reproduce: 1. Load http://www.peacekeeper.therichins.net/test3b.html in FF4 and Chrome 2. Notice that the avg FPS for FF4 is below Chrome Actual Results: FF4 is slower than Chrome Expected Results: FF4 to be as fast or faster than Chrome
Thanks for the testcase! If it's standalone, do you want to just attach it to this bug? The time breakdown on Mac (where Chrome is about 3x faster than us) is like so: 39% painting (18% building display lists and layers; 18% cairo actually painting, rest is Clip() and other noise) 16% doing the actual background color sets and all associated JS (12% for the sets themselves). 45% restyle processing. This breaks down as: 1% restyle tracker hashtable ops 12% ProcessRestyledFrames (about 2/3 in the InvalidateOverflowRect() calls) 11% ResolveStyleFor (actual rule matching is 6%; the GetContext call is 4%, the latter because it has to do the style fixups, which is forcing a WalkRuleTree looking for the display data and a ComputeDisplayData call). 9% CalcStyleDifference (getting, and recomputing, position and background structs). 7% ruletree GC. and some minor stuff. I'll try to figure out why we're recomputing display structs here, exactly.
Status: UNCONFIRMED → NEW
Component: DOM: CSS Object Model → Tracking
Ever confirmed: true
QA Contact: style-system → chofmann
Oh, right. All the "pixels" have float:left, so we can't cache the display struct in the ruletree. That's.... annoying. And the reason we're recomputing position structs is that the pixel width/height are all specified as inline style instead of via a class, so the position struct is cached right on the rulenode for the inline style rule.
I filed bug 608756 on the display struct thing, but we need a bunch more bugs filed on the slow bits here... The InvalidateOverflowRect stuff might go away in bug 539356. Some other noise that might go away is the rule processor data ctors/dtors (bug 598832).
I believe this is rederGrid03 in Peacekeeper 2.0. Fx Nightly is currently 3-4x slower than Chrome Dev in that benchmark.
For what it's worth, I just redid a profile of the testcase from comment 4. Still on Mac. 40% is restyle processing; this breaks down about evenly as ResolveStyleFor, CalcStyleDifference, ruletree GC, and the invalidate calls we make. 14% JS execution plus style setting (10% for the actual style sets) 45% painting. Building display lists is only 6% now, but another 6% is ComputeVisibilityForRoot, 5% is building layers, and the rest is almost entirely nsDisplayBackground::Paint). So not much changed, really. I wonder whether the paint time is less on Windows....
On Windows XP, nightly has jumped very nicely. There are three render grid tests: 10x5, 25x20, 85x50 (which is test3b.html). My numbers of yesterday, today and chrome. Yesterday Today Chrome 10x5: 88.46 166.34 167.96 25x20: 70.32 103.42 164.93 85x50: 4.95 5.15 17.79
What changed from yesterday to today? I really hope that jump is not from bug 608756 alone!
No, it turns out it is the setTimeout thing. I just did a reboot Between yesterday and today, the timer resolution must have been turned up so instead of being clamped to around 10ms, I was clamped to around 1ms. So, with the normal clamp, the times are: Yesterday Today Chrome 10x5: 86.45 87.28 140.40 25x20: 70.32 75.81 150.03 85x50: 4.95 5.24 18.22 It would be nice if Bug 640796 was fixed.
On the testcase from comment #4 I get Nightly - Avg: 5.828 Chrome 33 - Avg: 13.204 IE 11 - Avg: 8.750
We're way slower on linux than chrome, and https://bugzilla.mozilla.org/show_bug.cgi?id=608648#c1 is still valid.
You need to log in before you can comment on or make changes to this bug.