Closed Bug 1017256 Opened 6 years ago Closed 6 years ago

31.7% OSX tscrollx regression on May 28th (fx32) from push 883ebdb850ac

Categories

(Core :: Layout, defect)

All
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla32

People

(Reporter: jmaher, Assigned: mstange)

References

Details

(Keywords: perf, regression, Whiteboard: [talos_regression][dzalerts])

As seen on graph server we have osx 10.6 and 10.8 regressions in tscrollx:
http://graphs.mozilla.org/graph.html#tests=[[287,63,21],[287,63,24]]&sel=1401189418000,1401362218000&displayrange=7&datatype=running

I did a couple retriggers to ensure this was a real regression and nothing with the alignment of the moon (or other infrastructure, machine, noise issues):
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&fromchange=98644e8a0e12&tochange=4877e43fd90c&jobname=Rev4%20MacOSX%20Snow%20Leopard%2010.6%20mozilla-inbound%20talos%20svgr

This falls on 3 patches.
Here is information about the test:
https://wiki.mozilla.org/Buildbot/Talos/Tests#tscroll.2C_tscrollx

:mstange, can you please take a look at this.
Flags: needinfo?(mstange)
Thank you, I will. Bug 1016535 is the only bug of those three that could have an impact on this test.
Assignee: nobody → mstange
No longer blocks: 1012735, 1016525
Status: NEW → ASSIGNED
Flags: needinfo?(mstange)
thanks for picking this up.  Ask if something doesn't make sense.
Duplicate of this bug: 1016821
Depends on: 1018309
Depends on: 1018461
So, assuming bug 1009679 hadn't landed, the patch in bug 1018309 (which corrects a mistake in the patch for bug 1016535) would erase this regression. However, since bug 1009679 will stay in the tree, bug 1018309 probably won't make an impact. However, the subtest that was affected most is iframe.svg, and speeding that up is really simple (bug 1018461), and doing so will drop tscrollx numbers on 10.8 from ~3.72 to ~1.68.
thanks for staying on top of this!
I think we can call this fixed. :-)

https://groups.google.com/forum/#!topic/mozilla.dev.tree-management/oWLNaxi3aFM
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
(In reply to Markus Stange [:mstange] from comment #5)
> ... However, since bug 1009679 will stay in the tree, bug 1018309
> probably won't make an impact. However, the subtest that was affected most
> is iframe.svg, and speeding that up is really simple (bug 1018461), and
> doing so will drop tscrollx numbers on 10.8 from ~3.72 to ~1.68.

> I think we can call this fixed. :-)

The new numbers are great! thanks :)

I wasn't able to understand, however, if it fixes the issue which caused this regression, or fixed an unrelated issue which happened to affect the same sub-test which regressed with this bug.

Which is it?
It's a bit complicated. But I think this statement is true: If we had landed bug 1018461 before bug 1016535, the latter wouldn't have caused any regression.

The reason is as follows: Before either bug landed, the iframe in iframe.svg didn't have its own layer - it directly painted into the opaque ThebesLayer of its outer page and was repainted on every scroll. Then bug 1016535 landed and caused the iframe to get a component alpha layer. Now the repainting on every scroll painted twice as much (because that's how component alpha layers work: everything gets painted twice, once on a black background and once on a white background, and then the compositor can calculate a per-component alpha value for each pixel from both buffers). However, after 1018461, the iframe gets its own component alpha layer anyway, because it's actively scrolled, but it only repaints the small part that gets scrolled into view on every scroll and leaves the rest of the layer alone. So landing bug 1016535 on top of bug 1018461 wouldn't have changed the iframe's layerization.
Sounds like bug 1018461 is a general improvement that would have prevented this regression had it landed earlier than bug 1016535 and the other related ones. In my book that's as proper as it can get as far as fixing regressions go. Thanks :)
well bug 1018461 did cause a linux32 svg regression in iframe.svg;
https://datazilla.mozilla.org/?start=1401335442&stop=1401849835&product=Firefox&repository=Mozilla-Inbound-Non-PGO&os=linux&os_version=Ubuntu%2012.04&test=tscrollx&graph_search=59a10383f361,9a5636240f6c&tr_id=5759202&graph=iframe.svg&x86=true&x86_64=false&project=talos

The way graphs.mozilla.org works is we ignore the page with the highest value and report the average of the rest of the pages.  This means we have always overlooked iframe.svg.  I believe this is the only platform for which iframe.svg regressed
You need to log in before you can comment on or make changes to this bug.