Closed Bug 1004768 Opened 6 years ago Closed 6 years ago

Scrolling is jittery on the Vertical homescreen

Categories

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

All
Gonk (Firefox OS)
defect

Tracking

(feature-b2g:2.0, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S1 (9may)
feature-b2g 2.0
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: kgrandon, Assigned: kgrandon)

References

Details

(Keywords: perf, Whiteboard: [c=uniformity p=1 s=2014.05.09.t u=],[systemsfe])

Attachments

(1 file)

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.
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.
The issue as described seem slightly different, but I would not be surprised if the same patch will fix both of the issues.
See Also: → 998215
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.
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → All
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.
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.
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.)
(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.
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.
Flags: needinfo?(milan)
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.
Flags: needinfo?(milan) → needinfo?(bgirard)
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.
Keywords: perf
Whiteboard: [c=uniformity p= s= u=]
Priority: -- → P2
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.
Flags: needinfo?(bgirard)
Depends on: 1007350
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.
See the 'Frames' tab of the above profile. Focus in on the last block of composites.
Why do you say the transform from APZC is being rounded?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
(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.
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
Summary: Scrolling is jittery → Scrolling is jittery on the Vertical homescreen
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
Component: Panning and Zooming → Gaia::Homescreen
Product: Core → Firefox OS
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?
(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.
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.
Assignee: nobody → kgrandon
Status: NEW → UNCONFIRMED
Ever confirmed: false
Whiteboard: [c=uniformity p= s= u=] → [c=uniformity p=1 s= u=],[systemsfe]
Target Milestone: --- → 2.0 S1 (9may)
Removed here: https://github.com/mozilla-b2g/gaia/commit/85c4a3ec7929dbbd17f0d6fd348bfcdfd50c37f3
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(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.
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?
I suspect we will need project Silk to be perfect.
Whiteboard: [c=uniformity p=1 s= u=],[systemsfe] → [c=uniformity p=1 s=2014.05.09.t u=],[systemsfe]
feature-b2g: --- → 2.0
I filed bug 1017251 to track getting good rendering with 20 or so layers.
(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.
(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?)
Mass modify - set status-b2g-v2.0 fixed for fixed bugs under vertical homescreen dependency tree.
You need to log in before you can comment on or make changes to this bug.