845944 - Large 'janky' slowdown in panning on the Samsung Nexus 10

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[enrico]

User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16

Steps to reproduce:

surf (everywhere, also mozilla.org)


Actual results:

everything seems very very slow, in particular the scroll and the zoom


Expected results:

be fast such as firefox on the other devices. it's so slow that you can't use it!

Comment 1

[Aaron Train [:aaronmt]]

We've seen reports of this so I'm marking this as tracking for investigation.

Enrico, can you try out Firefox Beta on Google Play, Nightly (http://nightly.mozilla.org) for Android or Aurora (http://aurora.mozilla.org) for Android and report back if either are better?

Is the only thing that is slow scrolling and panning? How is interaction with the browser itself?

Comment 2

[enrico]

Firefox beta doesn't help. Soon as i can i will try the nightly.
The menu/options/desktop mode/exit are normally fast. The interaction on the web is slow if you scrolled before;  also the loading time seems slow compared to a nexus 7 (> not a problem of android 4.2.2 i think). Few times too much scroll can cause the block of the zoom. it's like to surf on an old pc with windows 98.

Comment 3

[enrico]

i tryed both, aurora and nightly. The problem still remain, no visible changes.

Comment 4

[Scott]

Same issue here, Nexus 10, 4.2.2. I've used Stable, Beta (From Play Store) and Nightly builds (download) but each have the same issue with terribly jerky scrolling.

With regards to the Beta version (20.0) i have no addons installed which could be causing conflicts, its a clean install.

Comment 5

[Aaron Train [:aaronmt]]

We have a Nexus 10 in our office we will take a look at it. Are there any particular URL's that seem to be the worst culprits for you?

Comment 6

[Scott]

(In reply to Aaron Train [:aaronmt] from comment #5)
> We have a Nexus 10 in our office we will take a look at it. Are there any
> particular URL's that seem to be the worst culprits for you?

None in particular that are worse than others, news.bbc.co.uk or reddit cause the issue (don't try reddit, you'll be on there all night and this'll never get fixed ;) ) 

Any website seems to be bad though.

Comment 7

[enrico]

in my case no, it's lagging everywhere.. i hope you you can find the problem, thanks! :)

Comment 8

[Scott]

I should also add that as well as being very jittery when scrolling, it's also very slow scrolling up and down as well. Not as speedy as it should be.

Comment 9

[Aaron Train [:aaronmt]]

Friends, I see this 'jank' on our office's Nexus 10 as well; from complex sites like BBC News to really simple text (about:credits), or http://kernel.org. I'll hand the device off to our mobile platform developers next week for investigation. I'm suspecting the core issue here is related to the resolution of the device; 2560x1600.

Comment 10

[enrico]

searching on internet, i saw that there weren't any problems with firefox and android 4.2.1 (if can help)

Comment 11

[Aaron Train [:aaronmt]]

If this is isolated to 4.2.2 only do we have any idea what new changes were introduced that may cause issues?

Comment 12

[enrico]

no idea, this is my first android device. maybe we can ask on xda..

Comment 13

[Christoph]

I can confirm hat this issue seems to have to do something with Android 4.2.2. I used Firefox on my Nexus 10 with Android 4.2.1 without any problems. Right after updating to 4.2.2 the problems with scrolling started. Could be a coincidence, but that seems not very likely to me. ;-)

Comment 14

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

I found a 4.2.2 changelog at http://www.androidpolice.com/2013/02/12/developer-changelog-heres-whats-new-in-android-4-2-2-jdq39/ but nothing much jumps out at me.

cset 6f7654d6658f1bd0eb9e6658aaf77aae23ac26df is kind of interesting in relation to our bug 805479, though.

Comment 15

[Chris Lord [:cwiiis]]

Think this is a dupe. kats has a fix.

Comment 16

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

Un-duping as comments in bug 815862 indicate this is probably a different issue.

Comment 17

[Aaron Train [:aaronmt]]

Did Ian leave his tablet with you? If not, should probably order one. I think this might be too late for 20 unfortunately.

Comment 18

[Chris Lord [:cwiiis]]

(In reply to Aaron Train [:aaronmt] from comment #17)
> Did Ian leave his tablet with you? If not, should probably order one. I
> think this might be too late for 20 unfortunately.

Not as far a I know. I'm at the performance work-week now and then I'm on PTO for a week, so I won't really be able to attend to it within the next two weeks regardless - is that ok?

Comment 19

[Kevin Brosnan [Ex-Mozilla]]

Is there anyone else who could make progress on this while you are traveling?

Comment 20

[Chris Lord [:cwiiis]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #19)
> Is there anyone else who could make progress on this while you are traveling?

snorp if he expensed a Nexus 10? Though I imagine he's pretty busy atm :) kats is going on holiday at the same time as me... gbrown or cpeterson perhaps?

Comment 21

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

(In reply to Chris Lord [:cwiiis] from comment #20)
> snorp if he expensed a Nexus 10? Though I imagine he's pretty busy atm :)
> kats is going on holiday at the same time as me... gbrown or cpeterson
> perhaps?

I won't be on holiday at the same time. I can take a look next week if there's a device that reproduces it in Toronto.

Comment 22

[Aaron Train [:aaronmt]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #21)
> I won't be on holiday at the same time. I can take a look next week if
> there's a device that reproduces it in Toronto.

Ian's tablet has 4.2.2 and yes.

Comment 23

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

Taking this from Chris then.

Comment 24

[enrico]

any news? :)

Comment 25

[Brad Lassey [:blassey] (use needinfo?)]

Kat's any update?

Comment 26

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

Sorry, I dropped the ball on this. I can take a look at it tomorrow.

Comment 27

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

I have the Nexus 10 now and I can reproduce the janky scrolling on mozilla.org. It seems fine when mozilla.org is zoomed out (on initial load) but the more I zoom in the jankier the panning is. I agree with Aaron that this is likely due to the large screen resolution, which is probably causing the uploads to the compositor to take very long. I can investigate.

Comment 28

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

Attachment: Long composite times!

I turned on the COMPOSITOR_PERFORMANCE_WARNING log and loaded mozilla.org and did some panning. The compositor spits out some pretty huge composite times. BenWa, suggestions on what we can do here?

Comment 29

[Benoit Girard (:BenWa)]

Here's a multi-threaded profile:
http://people.mozilla.com/~bgirard/cleopatra/#report=288bf542b8bf69b5ceb6ec1cd442156a2b828c56

We're hitting a symbol I've never seen before 'llvm::APFloat::semanticsPrecision(llvm::fltSemantics const&)'. That's accounting for this jank.

Comment 30

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

That function appears to be part of the LLVM float library, but it's trivial: http://llvm.org/docs/doxygen/html/APFloat_8cpp_source.html#l00769

Comment 31

[Benoit Girard (:BenWa)]

Right. It's just because they stripped their symbols but not those for some reason.

Here's a profile with some sample labels. Looks like it's an upload problem.
http://people.mozilla.com/~bgirard/cleopatra/#report=0251e4979055a3e8a8f8e14fbec41d5c2dd60fd5

Comment 32

[Benoit Girard (:BenWa)]

Confirmed obscene upload size. That's good news:

I/Gecko   (31487): Upload 80, 1792, 176, 256
I/Gecko   (31487): Upload 80, 1736, 3040, 806
I/Gecko   (31487): Time to upload 210
I/Gecko   (31487): Upload 80, 1792, 3040, 750
I/Gecko   (31487): Time to upload 114
I/Gecko   (31487): Upload 1492, 2556, 24, 4
I/Gecko   (31487): Upload 80, 1736, 176, 56
I/Gecko   (31487): Time to upload 11
I/Gecko   (31487): Upload 1492, 2556, 216, 85
I/Gecko   (31487): Time to upload 16
I/Gecko   (31487): Upload 80, 1736, 3040, 312
I/Gecko   (31487): Time to upload 73
I/Gecko   (31487): Upload 80, 1736, 3040, 806
I/Gecko   (31487): Time to upload 154
I/Gecko   (31487): Upload 80, 1792, 3040, 750
I/Gecko   (31487): Time to upload 112
I/Gecko   (31487): Upload 80, 1792, 688, 256
I/Gecko   (31487): Time to upload 32
I/Gecko   (31487): Upload 768, 1792, 1792, 256
I/Gecko   (31487): Time to upload 28
I/Gecko   (31487): Upload 80, 1792, 3040, 512
I/Gecko   (31487): Time to upload 49
I/Gecko   (31487): Upload 80, 2048, 3040, 494
I/Gecko   (31487): Time to upload 45
I/Gecko   (31487): Upload 80, 1792, 176, 256
I/Gecko   (31487): Upload 80, 1736, 3040, 806

Comment 33

[Scott]

Hi, so what dies this mean then? Easy fix or something more serious?

Comment 34

[Benoit Girard (:BenWa)]

I was hoping we could do something smart here but it doesn't appear to. I changed the path to use glTexSubImage2D and that's no faster.

It's apparently a know issues according to this:
http://stackoverflow.com/questions/15580619/slow-gltexsubimage2d-performance-on-nexus-10-android-4-2-2-samsung-exynos-5-w

Romain guy works on Google Graphics so it's a credible source.

Comment 35

[Benoit Girard (:BenWa)]

I should note here that's the time to upload a 256*256 tile is ranges from 4-10 millisecond. That's only a 26 MB/sec =\. Even slow phones can upload a tile in under 1ms.

Comment 36

[Scott]

Thanks for the feedback and tour work on this issue.

What puzzles me though, and excuse my ignorance here, is that chrome, Boat browser, Opera etc don't have this issue.


I can only assume they handle the pages differently than Firefox and use a different method.

The annoying thing though is that, if what you day is correct, this is an ARM driver bug with no apparent fix time.

Comment 37

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

After a discussion with BenWa today, I'm attempting to get in touch with the ARM developers to find out what the state of their investigation is so that we can figure out what the best thing to do here is.

http://forums.arm.com/index.php?/topic/16691-slow-upload-performance-on-nexus-10/

Comment 38

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

Reassigning to BenWa as he's looking into this now based on the info we got from ARM.

Comment 39

[Benoit Girard (:BenWa)]

Thanks to Kats we have a contact at ARM who's helping us work out the issue. Apparently the drivers incorrectly thinks that the texture is in-flight when we do a full replacement causing performance degradation. ARM reports that this will be fixed in the next release of their drivers but there is no estimate.

Meanwhile we're working on a work around for the issue. I tried using a new texture for every update but I'm still seeing 4+ms upload times. I'm hoping to hear back with other suggestions.

Comment 40

[enrico]

nothing? any news about arm driver?

Comment 41

[Kevin Brosnan [Ex-Mozilla]]

Needinfo to answer comment 40.

Comment 42

[Benoit Girard (:BenWa)]

No. I'll send another email.

Comment 44

[Benoit Girard (:BenWa)]

I got a response. The problem is caused by a faulty 565 texture upload path. Applying the patch in bug 803299 fixes the problem.

Chris can we make bug 803299 runtime switchable and detect the Nexus 10 to apply it.

Comment 45

[Chris Lord [:cwiiis]]

(In reply to Benoit Girard (:BenWa) from comment #44)
> I got a response. The problem is caused by a faulty 565 texture upload path.
> Applying the patch in bug 803299 fixes the problem.
> 
> Chris can we make bug 803299 runtime switchable and detect the Nexus 10 to
> apply it.

Interesting - it can already be set via a pref, but it happens on startup - making it switchable while the browser is live would be kinda hard, but I'm guessing that would be unnecessary to fix this?

Comment 46

[Benoit Girard (:BenWa)]

(In reply to Chris Lord [:cwiiis] from comment #45)
> (In reply to Benoit Girard (:BenWa) from comment #44)
> > I got a response. The problem is caused by a faulty 565 texture upload path.
> > Applying the patch in bug 803299 fixes the problem.
> > 
> > Chris can we make bug 803299 runtime switchable and detect the Nexus 10 to
> > apply it.
> 
> Interesting - it can already be set via a pref, but it happens on startup -
> making it switchable while the browser is live would be kinda hard, but I'm
> guessing that would be unnecessary to fix this?

Alright let's just focus on any solution where we can detect the Nexus 10 early enough. Also I think it will be interesting to use Nexus 10 as a test device for 32-bit mode and in this case we wont have to worry about the performance regression :).

Comment 47

[Pat Drummond]

Similar symptoms using Firefox beta 22.0 on android 4.2.1 on ASUS transformer pad TF700T (with or without keyboard).  Scrolling has become unusable - starts to scroll then jumps back to original location on page.  Fx unusable unless keyboard "down arrow" or "PgDn" can be used. On older versions of Beta (and probaby Android too) it worked find, but still too slow.  Throughout I've has 'firefox is not resonding' error popups.
BTW I nearly didn't find this because of the odd title. What on earth is janky?

Comment 48

[Aaron Train [:aaronmt]]

Can we verify if the same ARM driver is used on the TF700T?

Comment 49

[Pat Drummond]

(In reply to Pat Drummond from comment #47)
> Similar symptoms using Firefox beta 22.0 on android 4.2.1 on ASUS
> transformer pad TF700T (with or without keyboard).  Scrolling has become
> unusable - starts to scroll then jumps back to original location on page. 

Fixed:  Disabled "Quick Gestures" addon and scrolling now normal. :(  But slow loading still a problem. As I scroll down I will see a blank (dark blue) page until it decides to load.  Or I see the page in "blurred" text until it loads completely (just like some JPEGs)

Comment 50

[Kevin Brosnan [Ex-Mozilla]]

Doubtful this is the same bug Transformers have been using nVidia ARM chips. Best to file a new bug.

Comment 51

[meowdog3325132_]

(In reply to Kevin Brosnan [:kbrosnan] from comment #50)
> Doubtful this is the same bug Transformers have been using nVidia ARM chips.
> Best to file a new bug.

And find out whether or not that behaviour also occurs with the newest Nightly version.  http://nightly.mozilla.org/

Comment 52

[bug.zilla]

I can confirm this on a Samsung Note (4.1.2).  AOSP browser is significantly smoother. Not sure why Firefox is so jerky.

Comment 53

[lweddewe]

The nightly version 25.0a1 of the 05.07.2013 brings a significant improvement for the Nexus 10 with Version 4.2.2. 
Anyway it is fare away from the softness of the Chrome.
They are still some jerky left.
Checked it with the software www.mindmeister.com. 
Before this nightly build this software was unusable. 
Now it is not good yet but usable.

Comment 54

[Aaron Train [:aaronmt]]

I imagine that is the workaround recommended from ARM used in the patches from 803299 has potentially resolved this.

Comment 55

[enrico]

seems fixed with android 4.3 :) waiting others feedbacks!

Comment 56

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

Marking fixed. The switch to 24-bit should have fixed this, and comment 53 seems to agree with that. Comment 55 indicates that the drivers in Android 4.3 might no longer have this problem as well.

Comment 57

[Scoobidiver (away)]

Not fixed for the 23.0 timeframe.