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

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 2

[Markus Stange [:mstange]]

Thank you, I will. Bug 1016535 is the only bug of those three that could have an impact on this test.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

thanks for picking this up.  Ask if something doesn't make sense.

Comment 5

[Markus Stange [:mstange]]

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.

Comment 6

[Joel Maher ( :jmaher ) (UTC -8)]

thanks for staying on top of this!

Comment 7

[Markus Stange [:mstange]]

I think we can call this fixed. :-)

https://groups.google.com/forum/#!topic/mozilla.dev.tree-management/oWLNaxi3aFM

Comment 8

[Avi Halachmi (:avih)]

(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?

Comment 9

[Markus Stange [:mstange]]

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.

Comment 10

[Avi Halachmi (:avih)]

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 :)

Comment 11

[Joel Maher ( :jmaher ) (UTC -8)]

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