Closed
Bug 629146
Opened 13 years ago
Closed 5 years ago
Rendering does not keep up with kinetic panning
Categories
(Firefox for Android Graveyard :: Panning/Zooming, defect)
Firefox for Android Graveyard
Panning/Zooming
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: mbrubeck, Unassigned)
References
Details
(Keywords: perf)
Attachments
(1 file, 1 obsolete file)
22.09 KB,
patch
|
Details | Diff | Splinter Review |
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.
Updated•13 years ago
|
tracking-fennec: ? → ---
Comment 1•13 years ago
|
||
Comment 2•13 years ago
|
||
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.
Updated•13 years ago
|
Assignee: nobody → ben
Status: NEW → ASSIGNED
Reporter | ||
Updated•13 years ago
|
tracking-fennec: --- → ?
Updated•13 years ago
|
Attachment #507264 -
Attachment is obsolete: true
Comment 3•13 years ago
|
||
Comment 4•13 years ago
|
||
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•13 years ago
|
tracking-fennec: ? → 2.0b5+
Reporter | ||
Comment 5•13 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+ → ---
Comment 6•13 years ago
|
||
Agreed. This no longer blocks and we should do more to speed up rendering period.
Updated•13 years ago
|
Assignee: ben → nobody
Comment 8•6 years ago
|
||
No assignee, updating the status.
Comment 9•6 years ago
|
||
No assignee, updating the status.
Comment 10•6 years ago
|
||
No assignee, updating the status.
Comment 11•5 years ago
|
||
Closing all opened bug in a graveyard component
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•