Rendering does not keep up with kinetic panning

ASSIGNED
Unassigned

Status

ASSIGNED
8 years ago
6 years ago

People

(Reporter: mbrubeck, Unassigned)

Tracking

({perf})

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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.
(Reporter)

Updated

8 years ago
tracking-fennec: --- → ?
Keywords: perf
tracking-fennec: ? → ---
Created attachment 507264 [details] [diff] [review]
Rendering does not keep up with kinetic panning
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.
Assignee: nobody → ben
Status: NEW → ASSIGNED
(Reporter)

Updated

8 years ago
tracking-fennec: --- → ?
Attachment #507264 - Attachment is obsolete: true
Created attachment 507581 [details] [diff] [review]
Rendering does not keep up with kinetic panning
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).

Updated

8 years ago
tracking-fennec: ? → 2.0b5+
(Reporter)

Comment 5

8 years ago
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.
tracking-fennec: 2.0b5+ → ---
Agreed. This no longer blocks and we should do more to speed up rendering period.
Assignee: ben → nobody
You need to log in before you can comment on or make changes to this bug.