1004768 - Scrolling is jittery on the Vertical homescreen

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect, P2)

Description

[Kevin Grandon :kgrandon]

I am not sure if this is a graphics or apz issue, but I have noticed that scrolling can be particularly jittery on most devices. I am currently testing on a helix and it is pretty bad, it is also fairly bad on the new flame devices running latest gecko.

The panning is fairly smooth while it is tracking your finger, but becomes quite jittery when you let go before it comes to a stop.

This appears to manifest in most apps with scrollable areas. This is important to solve for our vertical homescreen as scrolling is a common use case.

Comment 1

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

There is a known issue on the Helix - bug 998215. This issue sounds different, but maybe take a look at that to make sure it's not the same.

Comment 2

[Kevin Grandon :kgrandon]

The issue as described seem slightly different, but I would not be surprised if the same patch will fix both of the issues.

Comment 3

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

To make this bug more actionable then, can you provide more specific STR? I spent some time scrolling around in the Settings app and a medium-workload contacts app on Helix but didn't see significant jitteriness or jank.

If you can provide a profile including the compositor thread that would be great as well, although STR I can repro with would be more useful overall.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

Right, as described, this is more of a placeholder. Some of it came out of the "now that we fixed bug 959089, does it help" conversation.

Comment 5

[Kevin Grandon :kgrandon]

Sorry for the vague bug guys. Still trying to get into a position where I can create actionable bugs for you guys. I tested with the patch from bug 959089, and I'm still seeing a bit of jitter near the end of a scroll. I don't really have good steps besides "scroll, then stop". Next step is to profile I suppose.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Are there specific apps you're talking about?  Like in the email app pre-bug-796474, jitter is expected because we fix-up scrollTop but the value we're reading is not the true value if APZ is actively scrolling.  (This has been addressed in bug 796474.)

Comment 7

[Kevin Grandon :kgrandon]

(In reply to Andrew Sutherland (:asuth) from comment #6)
> Are there specific apps you're talking about?  Like in the email app
> pre-bug-796474, jitter is expected because we fix-up scrollTop but the value
> we're reading is not the true value if APZ is actively scrolling.  (This has
> been addressed in bug 796474.)

I am seeing this with most apps with APZ scrolling. It is very apparent on a helix and flame device, and much harder to notice on a nexus4, though if you look very carefully you can tell some exists. I can reproduce this with either the settings app or the new homescreen.

Comment 8

[Kevin Grandon :kgrandon]

Attachment: Video of flame device and irregular scroll deceleration

This is a video that Geo took of scrolling the new homescreen on a 240 FPS camera. It is hard to see, but near the end of every scroll there is what appear to be slight pauses as the page decelerates.

Linking to Geos people account for now as Bugzilla doesn't like the large attachment. I can upload or send it somewhere else if it goes down.

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Having the video is great - I couldn't tell from it (and didn't really feel like getting a ruler out) to see if this is us getting the position wrong, or if it's "simply" a frame uniformity issue.  BenWa, can you try and reproduce this on a device we do have (Hamachi for now, next week Flame), and see if we can get the cool new uniformity graph you've been working on for this scenario, and see if we can tell what the main cause is.

Comment 10

[Benoit Girard (:BenWa)]

For now I only implement compositing frame uniformity, but I can also implement layer tracking which would let us get exact scroll smoothness (assuming the delay between glSwapBuffers return and the frame being displayed on the screen is constant).

I'm not surprised that this is the case since project silk is being worked on. I'll happily get the graph to confirm where we current stand.

Comment 11

[Benoit Girard (:BenWa)]

http://people.mozilla.org/~bgirard/cleopatra/#report=5c0b345a1b090b8360438acbea1db1668cd54b63&select=23760,26220

I just tried scrolling with the Flame on the Settings app and it's the best scrolling profile I've ever seen! We seem to have 4 to 10 (hard to tell) frame skips out of 150 frames. See the 'Frames' tab.

This bug is too general to be actionable. We need to have a specific STR and specific app. Likely also a specific device.

If the problem is with the new homescreen we should file a new bug with specific STR so that we can investigate that test case.

Comment 12

[Benoit Girard (:BenWa)]

I implemented bug 1007350 to help understand this problem.

Based on the results from this profile:
http://people.mozilla.org/~bgirard/cleopatra/#report=bcd5961db72c2ae2a16e730c26c3fb1d7c649f8c

We seem to have two problems:
1) We're seem to be rounding the transform from APZC.
2) We're not scheduling the APZC transform correctly? I need to double check.

Comment 13

[Benoit Girard (:BenWa)]

See the 'Frames' tab of the above profile. Focus in on the last block of composites.

Comment 14

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

Why do you say the transform from APZC is being rounded?

Comment 15

[Benoit Girard (:BenWa)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #14)
> Why do you say the transform from APZC is being rounded?

It looked that way but it's actually when we get an update from the main thread they are rounded. The APZC transform doesn't get rounded. I need to dig deeper.

Comment 16

[Benoit Girard (:BenWa)]

(In reply to Benoit Girard (:BenWa) from comment #12)
> We seem to have two problems:
> 1) We're seem to be rounding the transform from APZC.

Explained in Comment 15. I changed the graph to be in screen pixels to make this easier to read

> 2) We're not scheduling the APZC transform correctly? I need to double check.

That was a bug in parsing the layers dump. That's now fixed and deployed.


I collected several more profiles of the Flame scrolling the Settings app and the scrolling looks fine.

Comment 17

[Benoit Girard (:BenWa)]

Since I can only reproduce this on the Vertical homescreen and the video demo this I'm official turning this into a specific bug for the Vertical homescreen:

STR:
1) Open Settings
2) Select Homescreen, turn on the vertical homescreen
3) Pan

Comment 18

[Benoit Girard (:BenWa)]

The problem is cause by an abuse of will-change. The page ends up with a very complex layer tree that the device' GPU can't handle at 60 FPS. Removing this line solves the problem:

http://mxr.mozilla.org/gaia/source/dev_apps/home2/style/css/app.css#14

Comment 19

[Kevin Grandon :kgrandon]

Thanks, I'll take a look at that. Before we were doing more animation with each icon, but we couldn't get that to perform, so we took it away. We may be able to remove this now, but I wonder if we'd be trading pinch-to-zoom performance instead?

Comment 20

[Benoit Girard (:BenWa)]

(In reply to Kevin Grandon :kgrandon from comment #19)
> Thanks, I'll take a look at that. Before we were doing more animation with
> each icon, but we couldn't get that to perform, so we took it away. We may
> be able to remove this now, but I wonder if we'd be trading pinch-to-zoom
> performance instead?

Removing this means that there's going to be a startup delay to transforming each icon independantly to layerize them. But other then that startup delay they should enable relatively fine. Except that in your current design you're going to have too many layers when you do try to do that animation so you wont hit 60 FPS with them either, with or without will-change.

Comment 21

[Kevin Grandon :kgrandon]

Hmmm, I feel like the platform might want to limit what it layerizes if we opt into too many with will-change so we don't get into this situation.

In any case, I'll go ahead and make the update to remove the will-change property as it's hurting us here. Thanks a lot for taking the time to look into this.

Comment 22

[Kevin Grandon :kgrandon]

Removed here: https://github.com/mozilla-b2g/gaia/commit/85c4a3ec7929dbbd17f0d6fd348bfcdfd50c37f3

Comment 23

[Benoit Girard (:BenWa)]

(In reply to Kevin Grandon :kgrandon from comment #21)
> Hmmm, I feel like the platform might want to limit what it layerizes if we
> opt into too many with will-change so we don't get into this situation.

This is why will-change is not enabled by default on the web platform. Because we don't have that implemented and we trust privilege app to use it carefully.

Comment 24

[Kevin Grandon :kgrandon]

Thanks for the info. Scrolling seems to be much better without it. Unfortunately I still see uneven deceleration after a pan, but it's much less than before. I wonder if I am just picking up on some frame uniformity issues that we will address in the future though?

Comment 25

[Benoit Girard (:BenWa)]

I suspect we will need project Silk to be perfect.

Comment 26

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 27

[Benoit Girard (:BenWa)]

I filed bug 1017251 to track getting good rendering with 20 or so layers.

Comment 28

[Kevin Grandon :kgrandon]

(In reply to Benoit Girard (:BenWa) from comment #27)
> I filed bug 1017251 to track getting good rendering with 20 or so layers.

Cool, thanks! For this to work really well for us we would need 100+ layers (one for each app icon), but any improvement is definitely welcome.

Comment 29

[Kevin Grandon :kgrandon]

(Though I don't know how layers work if they are outside the viewport, so if we only need layers for things inside the viewport, maybe we will be ok?)

Comment 30

[Kevin Grandon :kgrandon]

Mass modify - set status-b2g-v2.0 fixed for fixed bugs under vertical homescreen dependency tree.