913228 - Scrolling performance is horrible in today's nightly

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Kevin Brosnan [Ex-Mozilla]]

Scrolling performance seriously regressed today.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=12e4307ff333&tochange=a40169f091ea

A lot of changes in the range but bug 711959 stands out.

Comment 2

[Dave Townsend [:mossop]]

Seeing this too, Nexus 7 and 4. In both they no longer continue to scroll after I stop touching the screen unlike previously.

Comment 3

[Aaron Train [:aaronmt]]

Related to bug 912806?

Comment 4

[Aaron Train [:aaronmt]]

regressions in scrolling test results for today's builds?

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

This is not the same as bug 912806 it was regressed by bug 907754. This was regressed by bug 711959 I've built on either side of bug 711959 6366f575b4c6 scrolls fine. f13c3491c9c8 does not fling.

Comment 6

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Talos agrees:

Subject: <Regression> Fx-Team - Robocop Pan Benchmark - Android 4.0.4
        - 423%

Regression: Fx-Team - Robocop Pan Benchmark - Android 4.0.4 - 423% increase
---------------------------------------------------------------------------
    Previous: avg 6106.708 stddev 603.222 of 12 runs up to revision 6366f575b4c6
    New     : avg 31925.883 stddev 8694.878 of 12 runs since revision f13c3491c9c8
    Change  : +25819.175 (423% / z=42.802)
    Graph   : http://mzl.la/18xpsPH

Changeset range: http://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=6366f575b4c6&tochange=f13c3491c9c8

Changesets:
  * http://hg.mozilla.org/integration/fx-team/rev/d6515c4d6cf8
    : Augustin Trancart <[e-mail]> - Bug 711959 - Add RenderTask and the necessary mechanisms to use it. r=kats
    : http://bugzilla.mozilla.org/show_bug.cgi?id=711959

  * http://hg.mozilla.org/integration/fx-team/rev/05c2d7b68a22
    : Augustin Trancart <[e-mail]> - Bug 711959 - Adapt LayerMarginsAnimator to use the new RenderTask mechanism. r=kats
    : http://bugzilla.mozilla.org/show_bug.cgi?id=711959

  * http://hg.mozilla.org/integration/fx-team/rev/f746195f5595
    : Augustin Trancart <[e-mail]> - Bug 711959 - Adapt JavaPanZoomController to use the RenderTask mechanism. r=Cwiiis, kats
    : http://bugzilla.mozilla.org/show_bug.cgi?id=711959

  * http://hg.mozilla.org/integration/fx-team/rev/0fb65049cb95
    : Augustin Trancart <[e-mail]> - Bug 711959 - Making BounceRenderTask time-based. r=kats
    : http://bugzilla.mozilla.org/show_bug.cgi?id=711959

  * http://hg.mozilla.org/integration/fx-team/rev/f13c3491c9c8
    : Augustin Trancart <[e-mail]> - Bug 711959 - Make FlingRenderTask time-based. r=kats
    : http://bugzilla.mozilla.org/show_bug.cgi?id=711959

Bugs:
  * http://bugzilla.mozilla.org/show_bug.cgi?id=711959 - Animations could be performed more efficiently

Comment 7

[Augustin Trancart [:autra]]

As I did the patches in fault, I can try to fix that.

I received two mails : 
- Robocop Pan Benchmark did +423%
- another one saying "Improvement: Fx-Team - Robocop Checkerboarding Real User Benchmark - Android 4.0.4 - 35.6% decrease"

Can you tell me what this means? I don't really know what these tests are suppose to check.

One possibilities is the fact we used nanoseconde instead of milliseconde to get current framerate. I'll try to investigate that.

Comment 8

[Augustin Trancart [:autra]]

f13c3491c9c8 is at fault, thanks to Capella for pointing that. The bad parts are the changes in Axis.java between lines 340 and 353.

This code was adjusting friction according to realFrameRate, thus calling getFrameAdjustedFriction at each frame (and not at startup only). But getFrameAdjustedFriction calls Math.pow and Math.log which are quite slow I believed.

Do we rollback this patch? Or do we find a faster way to calculate these?

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Attachment: Fix long division to use float division

I was able to reproduce the problem and investigated. I think the problem is actually much simpler - the long/long division in getFrameAdjustedFriction can round to zero because of the way Java does math. The attached patch fixes it for me locally, I pushed it to try to see the effect on talos: https://tbpl.mozilla.org/?tree=Try&rev=44361d7b3e75

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 800770 [details] [diff] [review]
Fix long division to use float division

Review of attachment 800770 [details] [diff] [review]:
-----------------------------------------------------------------

autra r+'d via IRC. Apparently his bugzilla account lacks permissions to do reviews?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

The talos regression got a little bit better but I think the numbers are unreliable right now anyway because we might actually be scrolling around on about:home (see bug 910106). Anyway this patch fixes the visible scrolling performance so I'm landing it:

https://hg.mozilla.org/integration/fx-team/rev/b5eae5bcf096

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b5eae5bcf096