Closed Bug 779582 Opened 12 years ago Closed 12 years ago

Scrolling and zooming are not smooth (regression)

Categories

(Firefox for Android Graveyard :: Toolbar, defect)

Product:
Firefox for Android Graveyard
Component:
Toolbar
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox14 unaffected, firefox15 unaffected, firefox16 unaffected, firefox17- affected, fennec17+)

Status:
VERIFIED WORKSFORME
Tracking Flags:
Tracking Status
firefox14 --- unaffected
firefox15 --- unaffected
firefox16 --- unaffected
firefox17 - affected
fennec 17+ ---

People

(Reporter: mcomella, Unassigned)

References

(
URL
)

Details

(Keywords: perf, regression, reproducible) 

0) Open latest Nightly (8/1)
1) Go to http://wiki.mozilla.org
2) Scroll around the page

Expected: Scrolling is smooth
Actual: Scrolling is not as smooth as it used to be.

After testing, possible regression with bug 779152. Present in (https://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1343755898/) but not previous builds.
Blocks: 779152
tracking-fennec: --- → ?
tracking-firefox17: --- → ?
I have a build with the TextureView change (bug 779152) backed out here: http://people.mozilla.org/~jwillcox/fennec-no-textureview.apk

It does feel every so slightly faster on my galaxy nexus, but really both of them kinda suck. We can back it out I guess, but wanted to see what others thought first.
Also note that bug 779152 will only affect phones running ICS and greater.
Ran the APK in comment #2 on my Nexus S (4.1.1) and it was marginally faster. Is there some other recent check-in affecting speed here?
(In reply to Aaron Train [:aaronmt] from comment #4)
> Ran the APK in comment #2 on my Nexus S (4.1.1) and it was marginally
> faster. Is there some other recent check-in affecting speed here?

It feels better on my Galaxy Nexus (4.0.4) though I agree it is slightly slower than it used to be (see Aurora for reference). mfinkle pointed me at bug 777357 when I initially mentioned this. Perhaps that is related to this second layer of slowness?
Ran Eideticker on the CNN tests on my GN (4.0.4) with today's (2012-08-01 nightly) and the build snorp just linked to. Results:

=== Results for org.mozilla.fennec ===
  Number of unique frames:
  [13, 274, 254]

  Average number of unique frames per second:
  [13.68421052631579, 20.889453621346885, 19.34010152284264]

  Checkerboard area/duration (sum of percents NOT percentage):
  [0.0, 11.494961320158271, 11.635416385477114]


=== Results for org.mozilla.fennec_snorp ===
  Number of unique frames:
  [229, 244, 237]

  Average number of unique frames per second:
  [17.458703939008895, 18.602287166454893, 18.091603053435115]

  Checkerboard area/duration (sum of percents NOT percentage):
  [56.40776580403626, 25.944315235382277, 41.23710991610487]

The results for the first run on org.mozilla.fennec seems to be an outlier (probably a bad capture). I'd just ignore it. 

That aside, I don't see a discernable difference in frames per second / num unique frames between the two builds (there's a fair range of results with what eideticker produces so minor differences are not significant). Snorp's build seems to do worse on the checkerboarding metric but I'd want to do more tests to confirm before confirming it.
The jank is pretty bad on my Galaxy Note (4.0.4)
I believe the troublesome patch was backed out – the last few Nightlies do not show the same inconsistent scrolling I filed this bug for. However, scrolling still feels *slightly* below Aurora levels (this could just be mental), though this is probably unrelated to the bug I labeled for possible regression.
I too am noticing a revert of past performance for the better now (08/08 Nightly). Can we identify what was backed out?
I agree, it does appear to be better in the latest nightly.
tracking-firefox17: + → ?
tracking-fennec: ? → 17+
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #10)
> I agree, it does appear to be better in the latest nightly.

If this works for you, then mark it works for me
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
This appears to have returned, at latest in the 8/15 Nightly. The problem is especially prominent when zoomed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The experience is a little less consistently terrible than before, however. Wikipedia mobile appears to be a good example site.
I redownloaded the 8/8 Nightly again (https://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2012-08-08-03-05-29-mozilla-central-android/) and it seems the problem still existed there when zoomed. However, the performance of the 8/8 Nightly is much worse than I remember it being and the latest Aurora seems to have similar issues so I wonder if something else is at play here. Perhaps it is my device.

Does anyone else seem jagged scrolling when zoomed in? I've been testing using http://en.m.wikipedia.org/wiki/Real%2B
Isn't this related to bug 780615?
Michael, what device(s) are you testing with?
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #16)
> Michael, what device(s) are you testing with?

Galaxy Nexus (Verizon 4G LTE), Android 4.0.4.

Scrolling (zoomed and unzoomed) performance with the latest Nightly seems acceptable now and feels like previous versions. Zoomed scrolling occasionally sees light jankiness when it's abused (rapidly scrolling or switching directions often) but it does not appear to be anything major.

As the issues I originally filed this bug for seem to be gone, I'm going to resolve it. Feel free to reopen if you can repo. Sorry for the wild goose chase.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WORKSFORME
I cannot reproduce this issue either. Closing bug as verified WFM.

--
Firefox 18.0a1 (2012-09-17)
Device: Galaxy Note
OS: Android 4.0.4
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.