here is a graph showing win8 and win7: http://graphs.mozilla.org/graph.html#tests=%5B%5B225,131,31%5D,%5B225,131,25%5D%5D&sel=1413894476000,1414067276000&displayrange=7&datatype=running win8 is the critical one (unfortunately we stopped running it in favor of win8 64 bit and it is posting now opt builds to pgo). But you can see the regression in the graph server. Here is the key revision that caused the problem: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2f7a7cce07b6&tochange=3ce0af074cf0

Please check again after the fix for bug 1080688 lands.

This is only likely to have been caused by: http://hg.mozilla.org/integration/mozilla-inbound/rev/71cefcb137d7 It seems like using the DrawTarget::FillRect/StrokeRect methods is slower than using the methods that take a Path object in this case? That's...weird. Certainly very unexpected. I've pushed some changes to Try to help figure out what's going on: baseline (current, regressed state): https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=34616d494f44 make us use the old Path consuming code paths: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=d07893ae33ec turn off path caching: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=e646dba4bc18 make us use the old Path consuming code paths _and_ turn off path caching: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=e9b6cc9e3b4a By way of background, since about the 4th October (bug 932762's landing) we've been caching Path objects for SVG geometry elements. This means that when we give elements their initial reflow we create and cache a Path object for them and reuse the cached Path objects during rendering. The two svg opacity tests each fill and stroke 2500 rects. This means that the tests take a while to load, and therefore they're reflowed and rendered incrementally as new rects arrive from the network and are ready to display. Path caching means that not only would each element benefit from having it's Path cached when it comes to paint, but because of the incremental rendering earlier rects may render multiple times and therefore benefit multiple times. Fast forwarding to this regression, bug 1074161 made us avoid Path objects completely in favor of calling the optimized DrawTarget methods. Bas thinks its unlikely the optimized methods backed by D2D would have any path creation overhead under the hood, so it's surprising that they would be slower than code that creates and caches paths (since the latter has _some_ creation overhead even if it avoids repeating it). Anyway, once the pushes above provide some results (a bunch of retriggers probably being required) hopefully we'll have a better idea of what's going on. This is certainly curious.

Equivalent pushes for Windows 8: baseline (current, regressed state): https://tbpl.mozilla.org/?tree=Try&rev=14c884783c19 make us use the old Path consuming code paths: https://tbpl.mozilla.org/?tree=Try&rev=b8cfd1c4be7a turn off path caching: https://tbpl.mozilla.org/?tree=Try&rev=1a82451f90fd make us use the old Path consuming code paths _and_ turn off path caching: https://tbpl.mozilla.org/?tree=Try&rev=dacddc8a7df0

And the original Windows 7/XP pushes again, since treeherder currently doesn't provide UI to get to graph server: baseline (current, regressed state): https://tbpl.mozilla.org/?tree=Try&rev=34616d494f44 make us use the old Path consuming code paths: https://tbpl.mozilla.org/?tree=Try&rev=d07893ae33ec turn off path caching: https://tbpl.mozilla.org/?tree=Try&rev=e646dba4bc18 make us use the old Path consuming code paths _and_ turn off path caching: https://tbpl.mozilla.org/?tree=Try&rev=e9b6cc9e3b4a

after bug 1080688 landed, we see a significant win in this test: http://graphs.mozilla.org/graph.html#tests=%5B%5B225,131,25%5D,%5B225,131,31%5D%5D&sel=none&displayrange=7&datatype=running overall, we have a win and we could consider closing this bug.

Bug 1080688 improved performance for a different reason. We should still understand this regression before deciding to close this bug or else we lose out on a potential win. Besides that I'd especially like to understand why a Moz2D API that is supposed to be optimized would be slower than the regular Moz2D API. I decided to start over on the pushes so that we can get better graph data. Here are those pushes: Baseline (mozilla-inbound tip from a few hours ago (after bug 1080688 FWIW)): https://tbpl.mozilla.org/?tree=Try&rev=ead242199696 Full backout of bug 1074161: https://tbpl.mozilla.org/?tree=Try&rev=0c92c4cc25fc Partial backout of bug 1074161 to get data purely on the Path vs. FillRect/StrokeRect fastpaths: https://tbpl.mozilla.org/?tree=Try&rev=5ad6b7df1601 Graph data: http://graphs.mozilla.org/graph.html#tests=[[225,113,33],[225,113,35],[225,113,31],[225,113,25],[225,113,37],[225,23,21],[225,23,24]]&sel=1414386349245.2441,1414392136805.0527&displayrange=7&datatype=running I suggest hiding all but one set of data when viewing this since the colors are not unique to one set. There's no real difference for the results of the full and partial backouts, so I think we can be fairly confident that any perf changes are purely down to the implementations of the two Moz2D APIs being different. Based on the above graph data, [keeping] the patch for bug 1074161 causes the following changes to our perf on the 'svg opacity' tests: Win 8 non-PGO is pretty much unchanged Win 7 non-PGO is about 3% slower Win XP non-PGO is about 3% faster Ubuntu HW 12.04 non-PGO is about 100% slower Ubuntu HW 12.04 x64 non-PGO is about 3% faster MacOSX 10.6 is about 4% faster MacOSX 10.8 is about 5% faster Bas, have you any ideas why changing to use DrawTarget::FillRect/StrokeRect would have caused Win 7 non-PGO to have gotten a bit slower, and especially why Ubuntu HW 12.04 non-PGO would now be taking about twice as long?!

I do not see this on mozilla-beta, can we close this?