789746 - Page jitter while scrolling manually

Status: RESOLVED WORKSFORME

(Firefox for Metro Graveyard :: General, defect)

Description

[Jim Mathies [:jimm]]

This isn't related to performance, it has something to do with the way we are handling mouse input while the user scrolls a web page with their finger.

STR:

1) open a suitable text based page (http://www.techmeme.com/)
2) slowly pan the page up or down with your finger
3) modestly flick the page up or down to kick in kinetic scrolling

For #2, you'll see page jitter as you scroll the page
For #3, you'll see smooth scrolling

Comment 1

[Jim Mathies [:jimm]]

Seems part of this is related to jank in painting, here are some paint times from a modest flick of a google images page:

paint: 8.089367270527873 
paint: 6.070713809167501 
paint: 7.132960435177665 
paint: 4.903910299181007 
paint: 5.835941909987014 
paint: 6.492148611869197 
paint: 4.967414173588622 
paint: 5.452994303894229 
paint: 6.559501205978449 
paint: 8.981628778215963 
paint: 11.916918971634004 
paint: 11.669959460152313 
paint: 11.918843331455719 
paint: 14.867604043742176 
paint: 8.293990865699016 
paint: 14.068994714471046 
paint: 8.002129624830559 
paint: 11.48778672964545 
paint: 89.04077077028342 
paint: 15.194103761517908 
paint: 6.161800174450036 
paint: 5.752552984107751 
paint: 68.54954585107043 
paint: 13.179940473113675 
paint: 8.529404218192212 
paint: 7.9219479652820155 
paint: 7.755811566719785 
paint: 8.35108020727057 
paint: 6.782726946170442 
paint: 4.829501719097607 
paint: 5.669164058053866 
paint: 4.432442140940111 
paint: 5.014881715993397 
paint: 68.27307948889211 
paint: 14.787422384135425 
paint: 7.275363062566612 
paint: 7.186201057105791 

The sporadic large numbers represent the jank. Note the cpu usage during this is always low, around 6-7% so the system has plenty of spare cycles.

Comment 2

[Jim Mathies [:jimm]]

Attachment: paint times

From a manual scroll, the x,y values dx, dy. We request a paint on the first via mozRequestAnimationFrame and wait for the paint to happen before requesting another.

Comment 3

[Jim Mathies [:jimm]]

Taras, any chance that profiler of yours might help me here? I'd like to figure out what the system is doing during the long waits on paint.

Comment 4

[(dormant account)]

(In reply to Jim Mathies [:jimm] from comment #3)
> Taras, any chance that profiler of yours might help me here? I'd like to
> figure out what the system is doing during the long waits on paint.

It's Benoit's profiler. I suspect this might be GC/CC due to JS executing in event-handlers. In general the problem is that background tab or any tab activity can jank you. We need an android-style async UI to solve this.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Taras Glek (:taras) from comment #4)
> (In reply to Jim Mathies [:jimm] from comment #3)
> > Taras, any chance that profiler of yours might help me here? I'd like to
> > figure out what the system is doing during the long waits on paint.
> 
> It's Benoit's profiler. I suspect this might be GC/CC due to JS executing in
> event-handlers. In general the problem is that background tab or any tab
> activity can jank you. We need an android-style async UI to solve this.

Ah didn't know Benoit wrote that. Will chat with him. As far as the jank goes I don't think it is entirely a threading issue -  scrolling the desktop on the same page / same tablet is smooth. The metrofx issues may have something to do with the way we are scrolling content in the metro browser - we aren't using a regular scroll bars.

Comment 6

[Matt Brubeck (:mbrubeck)]

Optimizing or eliminating the JS code that runs during scrolling might help, like bug 632072 if we are still using that code.

Comment 7

[Jim Mathies [:jimm]]

we switched to using the dom for scroll. no longer reproducible.