Right now, we have the situation where we'll end up with an initial paint on a page with a displayport that doesn't really make sense for the page. For tiling, this will sometimes cause us to not paint enough (though bug 978248 makes that much better by expanding out the displayport to tile aligned coords always). We seem to use the last frame metrics as the initial metrics for a new page: http://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp#598 This means that if an app has, say, a 1400-px high page and you click on a link to navigate to another page in the app, we use that 1400 as the initial metrics even if that second page is much bigger or smaller. In this case (on a nexus 4), this causes the initial paint of a second, much longer page, to not have any additional tiles for scrolling which results in checkerboarding until things catch up. The additional full-displayport paints get kicked off only on first scroll.
This turned out to be a trivial fix: TabChild::HandlePossibleViewportChange() was calculating a displayport based on the old scrollable rect, just a few lines before it queried the new scrollable rect. Moving the displayport calculation to just after querying the new scrollable rect fixes the problem. Try run: https://tbpl.mozilla.org/?tree=Try&rev=1ef0182b9861
Attachment #8385721 - Flags: review?(tnikkel)
Attachment #8385721 - Flags: review?(tnikkel) → review+
Does this fix improve the buffer rotation scenario at all?
Uhm, no idea. Are you thinking for 1.3? It might, but could also maybe make things worse, since we'd be potentially painting a larger than before displayport for the initial display. (Longer initial paint, faster initial scroll)
Excellent. No for 1.3. Unfortunately, no 1.3- flag, so hopefully this comment will do.
Assignee: nobody → botond
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.