1511731 - Slow loading, janky scrolling and delayed / pixelated painting on dailymail.co.uk

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect, P3)

Description

[bug.zilla]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

I've taken the liberty to "reopen" this bug.

It's linked to these:
https://bugzilla.mozilla.org/show_bug.cgi?id=755259
https://bugzilla.mozilla.org/show_bug.cgi?id=861504
https://bugzilla.mozilla.org/show_bug.cgi?id=1104280

The site is indeed very badly designed, but it is somewhat popular in the UK and the scrolling and loading performance on v. 63 remains slow. This is on a Huawei MediaPad M8 Lite.


Actual results:

Loading is slow, scrolling is janky and in some cases content loads with a delay (white space flashes) or content is pixelated.

This short clip demonstrates it:
https://imgur.com/a/9nMnnXh


Expected results:

Firefox Focus does not have this issue.
Scrolling is as smooth (if not smoother) as Chrome.

Thanks

Comment 1

[miralobontiu]

Hi,

I was able to reproduce the issue. Indeed, on Nightly 65.0a1, the page scrolling is "janky", the pictures are pixelated, and some articles load with delays.
I could definitely see a difference between the latest Nightly 65.0a1 (2018-12-04) and Focus 8.0.1.

Tested with Motorola Nexus 6 (Android 7.1.1).

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix in 64 but we could still take a patch in 65/66.

Comment 3

[Chris Peterson [:cpeterson]]

Tagging [qf] for Android performance investigation. Scrolling issues are a common user complaint for Gecko on Android.

Does this problem also affect the geckoview_example app or just Fennec?

Comment 4

[Vicky Chin [:vchin]]

Profile of page load on Moto G5 using latest GV example shows pageload taking a long time.
https://perfht.ml/2A7m8RZ

Comment 5

[Vicky Chin [:vchin]]

Chose classic site, takes a long time for the greyed out screen to go away before I can scroll. 
https://perfht.ml/2A7mWpZ

Comment 6

[Markus Stange [:mstange]]

Here are some profiles of scrolling on the classic site:

https://perfht.ml/2R8cxUw - lots of checkerboarding, some scroll motions had long delays
https://perfht.ml/2R8cs3a - more images present now, lots of low-resolution rendering

(At least progressive tile rendering seems to be working as intended: https://perfht.ml/2R3TdYN ...)

Enabling WebRender didn't help; it caused 1+ second composites: https://perfht.ml/2R3ylkb

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

FWIW, we do have prefs for device.sensors.*

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Looking at some of the profiles here, I think we can break this up into several problems:

1. Slow paints: https://perfht.ml/2PSW7L6
2. Lots of deviceorientation events are being fired and causing JS to run: https://perfht.ml/2PSX1as
3. In vchin's profile from comment 4, there's a crapload of JS running before first paint: https://perfht.ml/2PRJAYD

I think someone from Graphics needs to look at (1).

I think we need to file a new bug to look at potentially throttling deviceorientation events (I'll file that next).

I think (3) would be helped by trying to defer more JS that tries to run before first paint.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Hey djvj, was there a bug for the "defer more JS from running before first paint" stuff we talked about last week?

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Hey jrmuizel, is there anybody from graphics you could recommend who could look at the profiles in here? We've got some pretty slow rasterization going on on Android, and WebRender doesn't appear to help.

Comment 11

[Kannan Vijayan [:djvj]]

I don't think there is a bug that tracks it yet, but maybe smaug made one.  If not, I can make a meta-bug and start linking things up as dependencies to that.

Keeping needinfo.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

I think profiles are not very good. Things are taking much longer than they should and I suspect things are starved for some reason. It would be good to confirm that these times reflect actual running times without the profiler running.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking fix-optional for 65 and 66 so that these already triaged issues don't show up repeatedly in weekly regression triage. Happy to take a patch in nightly.

Comment 14

[Vicky Chin [:vchin]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)
> I think profiles are not very good. Things are taking much longer than they
> should and I suspect things are starved for some reason. It would be good to
> confirm that these times reflect actual running times without the profiler
> running.

I can confirm that we still get the slow painting and delayed/pixelated painting without the profiler running on the latest GV example.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Can we get a profile with a low sampling interval? every 200ms or something like that?

Comment 16

[Bobby Holley (:bholley)]

Testing on today's nightly on an android tablet, the pixelation/checkerboarding situation is much better with WR enabled.

Comment 17

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.