Closed Bug 994861 Opened 6 years ago Closed 6 years ago

4.89% tscroll regression on win8 as a result of bug 987680

Categories

(Core :: Layout, defect)

x86_64
Windows 8
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla31
Tracking Status
firefox31 - ---

People

(Reporter: jmaher, Assigned: tnikkel)

References

Details

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

Attachments

(1 file)

Attached patch patchSplinter Review
Bug 896443 added position: relative to root scrollbars on mac and Windows. It should have only been for overlay scrollbars. Since the scrollframe code uses positioned to indicate the scrollbars should be placed over the content (like overlay scrollbars) this made the classic scrollbars be placed higher up in the page.

This fixes the regression for me, and in general doing anything that put the scrollbars back into the background layer fixes the regression.
Assignee: nobody → tnikkel
Attachment #8405720 - Flags: review?(roc)
Blocks: 896443
Markus' comment from bug 987680 for reference.

(In reply to Markus Stange [:mstange] from comment #31)
> (In reply to Joel Maher (:jmaher) from comment #30)
> > We havea 4.89% tscroll regression on win8 as a result of the landing in
> > comment 27.  
> 
> We had the inverse improvement on March 20th from
> http://hg.mozilla.org/integration/mozilla-inbound/rev/d5acc6457aaa which
> introduced the bug that this patch fixes:
> http://graphs.mozilla.org/graph.html#tests=[[287,131,31]]&sel=1395273391151.
> 3914,1395298910292.08,6.9595184853549386,8.
> 032138857196667&displayrange=30&datatype=running
This now makes sense since http://hg.mozilla.org/integration/mozilla-inbound/rev/d5acc6457aaa accidentally moved scrollbars into the background layer (even overlay scrollbars sometimes), inadvertantly fixing the regression caused by bug 896443.
The automated mailer reported this as a 8.19% improvement, so we fixed the regression and then improved even more.
great!  Thanks for fixing this.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
I'll let it get resolved when the sheriffs merge it to central as usual.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
https://hg.mozilla.org/mozilla-central/rev/8e5f7f4427df
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
rather than open another bug, this seemed to have caused a regression on linux (32 and 64) in tscroll.

linux: 3.6%
linux64: 6.2%

I have done some retriggers to weed out noise and ensure it was this push:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&fromchange=cbe169081f1c&tochange=376496720a0e&jobname=Ubuntu%20HW%2012.04%20mozilla-inbound%20talos%20svgr

here is a link to the graph:
http://graphs.mozilla.org/graph.html#tests=[[287,131,33]]&sel=1397417505000,1397590305000&displayrange=7&datatype=running
:tn, can you common on the tscroll linux regressions?  Is that expected from this?
Flags: needinfo?(tnikkel)
No, very much not expected. The patch only changed the two files
toolkit/themes/osx/global/nativescrollbars.css
and
toolkit/themes/windows/global/xulscrollbars.css
which I'm hoping have no effect on linux builds. I've done several try pushes to see what's up and I'll proceed based on the results of those.
Flags: needinfo?(tnikkel)
thank you, let me know if I can help at all
I think windows files are often used on linux as well.
Based on my try pushes that appears to be the case thanks.

So I'm guessing this changed the layer structure of the page being tested somehow resulting in slightly worse performance. Not sure if we can do much about that as classic scrollbars are supposed to be in the background layer.
There's nothing unusual going on with the talos pages and the scrollbars, and it doesn't matter if the scrollbars get their own layer or not. The only thing that matters if the relative ordering of the scrollbars and the canvas background items in the paint stacking order. scrollbars below canvas bg items -> slow. scrollbars above canvas bg items -> faster.
thanks for the details here :tn.

Here in datazilla we can view the specifics of each test:
https://datazilla.mozilla.org/?start=1397376632&stop=1397741678&product=Firefox&repository=Mozilla-Inbound-Non-PGO&os=linux&os_version=Ubuntu%2012.04&test=tscrollx&graph_search=8e5f7f4427df&x86_64=false&project=talos

we actually improved iframe.svg, but regressed:
tiled-downscale.html (small)
tiled-fixed-downscale.html (larger)
tiled-fixed.html (larger)
tiled.html (small)

here is the source for tiled-fixed.html:
http://hg.mozilla.org/build/talos/file/35127ce89efd/talos/page_load_test/scroll/tiled-fixed.html

and for tiled-fixed-downscale.html:
http://hg.mozilla.org/build/talos/file/35127ce89efd/talos/page_load_test/scroll/tiled-fixed-downscale.html

of course all the files are here:
http://hg.mozilla.org/build/talos/file/35127ce89efd/talos/page_load_test/scroll

If the *fixed* files have scrollbars below canvas bg items, that would make all make sense.  I am not sure there is anything to do here.
(In reply to Joel Maher (:jmaher) from comment #16)
> If the *fixed* files have scrollbars below canvas bg items, that would make
> all make sense.  I am not sure there is anything to do here.

I'm not sure why that would make sense. The canvas background items and the scrollbars don't overlap at all, so one does not actually paint directly on top of the other, it's just the internal ordering of the items. It looks like we are doing the same paint calls of the same areas no matter which order they are painted in.
While looking into this I noticed bug 1000266, which coincidentally gets a 5% tscroll win on linux. It's unrelated though, so it doesn't fix the regression in any direct manner (the subtests with fixed bgs gain a lot, other subtests end up slightly behind where we were before, the rest are about neutral).
on Aurora after the uplift we have a 3.69% regression on linux32:
http://graphs.mozilla.org/graph.html#tests=[[287,52,33]]&sel=1396793141680,1399385141680&displayrange=30&datatype=running

It seems to be related to this bug as best as I can find by looking at improvements and regressions.  The win we got in bug 1000266 was great on non PGO, but minimized on PGO.
That's odd. But this entire bug seems a bit odd. Anyways, bug 1000266 wasn't meant to address this specific regression, it was just something I noticed while looking into it that got us a coincidentally similar improvement.

Looking at 32 and 64 bit data on linux, both PGO and non-PGO series I see some other weird trends. Bug 1000266 wins back something in all cases, but it varies from all of the regression, to maybe a quarter of it. And there is no clear pattern between 64/32bit or pgo/non-pgo.

Non-PGO 32bit, bug 1000266 gets us back to where we were before this regression.
PGO 32bit, bug 1000266 wins back about half the regression.
Non-PGO 64bit, bug 1000266 gets back maybe a quarter of the regression.
PGO, 64bit, bug 1000266 gets back about 75% of the regression.

I also saw another improvement from another bug, bug 1000875 is another win on this test.

64bit, PGO, better than before.
64bit, non-PGO, improved, but still slightly worse then before.
32bit, PGO, back to where we were before.
32bit, non-PGO, better than before.

Still no pattern for 32/64bit or pgo/non-pgo.
I have been a bit baffled by the inconsistencies here as well.  Usually there is more of a pattern.  Shall we retitle this to be 'the twilight zone' :)

Is there anything we can do (or should do) for linux32 <5% tscroll regression on pgo only?  Should we file a new bug to track that as it is specific and not really related to this bug?
Blocks: 1008197
You need to log in before you can comment on or make changes to this bug.