629146 - Rendering does not keep up with kinetic panning

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Panning/Zooming, defect)

Description

[Matt Brubeck (:mbrubeck)]

When panning continuously through a long page on device, it's easy to reach checkerboards and then never see any content until after scrolling stops.

Since we update the displayport based on where the viewport is *now*, and it can take a few hundred milliseconds for the updated displayport to finish rendering, the viewport might have moved far past the content by the time anything renders.

During kinetic panning, we should update the displayport based on a prediction of where the viewport *will* be when the content is finally rendered.

Comment 1

[Benjamin Stover (:stechz)]

Attachment: Rendering does not keep up with kinetic panning

Comment 2

[Benjamin Stover (:stechz)]

This patch is a little weird. It heavily throttles the displayport calls for a pan to one for most cases.

The result is a little jarring on desktop. Sometimes a little gray will show immediately after you start panning, and then content will just magically start scrolling in towards the end of the pan.

Sadly, updating the displayport is slow most of the time. I'm not sure we can do a lot better than this in the frontend. The next step is to make content rendering faster.

Comment 3

[Benjamin Stover (:stechz)]

Attachment: Rendering does not keep up with kinetic panning

Comment 4

[Benjamin Stover (:stechz)]

So I think we're getting pretty close in the latest patch.
* displayport is updated just once during a kinetic pan
* the update area is at best the union of the start visible rect, the end visible rect, and everything in between to reduce the amount to render
* after the pan finished, the cached area gets restored to the area
* a preference controls the approximate amount of memory we're willing to cache, and another preference controls the ideal widthToHeight ratio. I've set these at 8MB and 1:1, respectively. The ratio isn't applied always: it's just a suggestion. During panning and for super skinny or super wide pages, the browser automatically picks the best ratio for optimal memory usage.

I tried playing with setResolution, but it's obviously a lot less pretty and it doesn't noticeably improve content refresh.

Further things we can do:
* CPU contention. We noticed today that checkerboarding had a severe impact on displayport rendering. Hardware acceleration and optimized JS loop could make this a non-issue!
* Use more memory! If we could keep track of the available memory for Android, we could dynamically alter the area easily now.

Things left to do with this patch:
* We need a new method for iframe panning. Setting other displayports to the minimal amount when panning iframes should be enough.
* I turned off updating the scroll offset to stop flashing at the end of pans. Turn this back on (somehow without flashing).

Comment 5

[Matt Brubeck (:mbrubeck)]

Resetting blocking-fennec flag.  With bug 629475 and bug 633986 fixed, rendering does keep up with kinetic panning on most sites.  And this change now makes things worse rather than better on some sites.  We might still want some variant of this approach, but I don't think it needs to block b5 anymore.  If anyone thinks this should block Fennec 4.0, feel free to re-nominate.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Agreed. This no longer blocks and we should do more to speed up rendering period.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 11

[BMO Automation]

Closing all opened bug in a graveyard component