982534 - ScrollGraph output inconsistent data

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Performance, defect, P2)

Description

[Andre Graziani (:graziani)]

Attachment: ScrollGraph_output.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140306030201

Steps to reproduce:

Enable ScrollGraph and remove comments from its output log.
Scrolled Settings list down and captured the ScrollGraph log of the relevant layer.


Actual results:

Log is inconsistent with what user sees on display (see attached log)


Expected results:

Log should be consistent

Comment 1

[Andre Graziani (:graziani)]

Attachment: Patch to improve ScrollGraph output (v1)

I made a small patch that makes the output consistent (at least for my purpose). But I filtered the layers by TYPE_CONTAINER only.
In this patch, I consider the scroll offset of the layers.

Comment 2

[Andre Graziani (:graziani)]

Attachment: ScrollGraph output in a chart before and after patch v1

Comparison of the ScrollGraph log output in a chart, before and after the patch.
The Overlay of the ScrollGraph also presents the same kind of inconsistency.

Comment 3

[Andre Graziani (:graziani)]

Mason Chang, with this patch I can use ScrollGraph to analyze the uniformity of the drag movement.
Does this patch makes sense for you?

Comment 4

[Mason Chang [Inactive] [:mchang]]

Hi Andre, yes this makes sense to me. :benwa would be a better person to review if you want to land it.

Comment 5

[Benoit Girard (:BenWa)]

Scrollgraph is meant to measure the scroll velocity. Now you're measuring the scroll position. That just means that reader has to work harder to derive the scroll velocity. Your solution only works on container layers which is an artificial limitation.

The graph for scroll position will be smoother then the graph for velocity. That's because having monotonically decreasing scroll velocity is harder and is required for smooth scrolling.

Having monotonically increasing scroll position (like your second graph) just means that we never scroll backwards. That's easy to get right and doesn't mean we're scrolling smoothly.

Also to properly graph this you want your X axis to be the current time, not the number of refresh.

Comment 6

[Mason Chang [Inactive] [:mchang]]

I think I have led LG astray, I apologize for that. If we just need to measure frame uniformity, that is X pixels per touch event / screen refresh, layer position will work rather than scroll velocity. If that's the case, the code should work since it works on container layers and the layer transform for APZ layers should be on container layers. 

What might work better then, is to track the touch event to the next composite, then check the layer position to ensure a uniform frame. As long as we're triggering refreshes at each vsync, this should work (bug 980241).

Comment 7

[Andre Graziani (:graziani)]

(In reply to Benoit Girard (:BenWa) from comment #5)

Thanks for your analysis.

> Scrollgraph is meant to measure the scroll velocity. Now you're measuring
> the scroll position.

I actually just put in a chart what the printf gives me (for a specific layer). Printf gives me the layer position, not velocity (before the patch as well).
Velocity is calculated later, based on these positions. The ScrollGraph will show the velocity on its overlay (even after the patch).

> Your solution only works on container layers which is an artificial limitation.

Right. In my specific case just container layers are enough, but it is a limitation for sure.

> Also to properly graph this you want your X axis to be the current time, not
> the number of refresh.

Yes, for that I should include some sort of timestamp on the printf.

Comment 8

[Andre Graziani (:graziani)]

(In reply to Mason Chang [:mchang] from comment #6)

> What might work better then, is to track the touch event to the next
> composite, then check the layer position to ensure a uniform frame.

Yes, that would give us more information about uniformity. But we are not going to have touch events during fling (not sure Mozilla uses this term, it is when the content keeps scrolling after I release my finger).

Comment 9

[Andre Graziani (:graziani)]

Bug 990832 does exactly what the patch proposed here is doing.

Comment 10

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Jeff, can you add some detail to the bug as to why this needed to be reopened?

Comment 11

[Jinho Hwang [:jeffhwang]]

Hi Geo,

I made a tool to visualize 'Frame Uniformity' and it's using the log data printed by Scroll Graph.
(Plz See, Bug 990832)
So, the bug 990832 is depend on this bug. 
But the problem is that the layer position data printed by Scroll Graph is not always collect.
Some times it prints meaningless data as mentioned Comment #1.

Thus, we should clean-up this bug first thought.
I hope that this a little detail helps you to understand why this bug is important.

Thanks.

Comment 12

[Mason Chang [Inactive] [:mchang]]

From comment 11, since frame uniformity shouldn't depend on the scroll graph anymore, we can close this.