nsLayoutUtils::CalculateCompositionSizeForFrame() is not affected by the
document resolution when called for the root content document's root
scroll frame. When determining the root composition bounds in order to
calculate a displayport base, if the frame used is the RCD-RSF we must
be sure to scale the bounds ourselves by the document resolution.
MozReview-Commit-ID: ATctmEYvWIJ
Bug 1241917 made it so that a subframe's displayport base is restricted
to the root composition bounds (in addition to its previous
restrictions). This involved an expensive coordinate transformation
causing a scrolling performance regression.
This avoids restricting the displayport base to the root composition
bounds unless the frame has a display port, avoiding the expensive
computation unless necessary.
MozReview-Commit-ID: FVacUscAfu2
It's not obvious that it does this (unless you read the comment or the code), and we don't gain much by doing it.
Also we need to split it up for the next patch in this bug.
Previously displayport bases were computed as the intersection of the
scrollport with the dirtyrect. However the dirtyrect covers what is
rendered, and with displayports what we render can be much larger than
what is visible. With displayport bases intended to represent what was
visible, this was a problem. By restricting them to the root composition
size this makes them more closely match what is visible. To do this more
properly we'd want to intersect the dirtyrect with the scroll clip of
every ancestor scroll frame, not just the root composition bounds.
Note that nsMathMLContainerFrame and its subclasses are unchanged since
they are not target of fullscreen (and thus no backdrop frame), and they
have an assertion to ensure we really don't pass any unexpected list in.
Displayport margins change by small amounts on almost every single scroll. We do not want to update image visibility nearly that often.
As the comment, and the original bug (bug 1169881) suggest this is only meant to catch rather large changes in display ports as we already have means to trigger an image visibility update via a scroll position change and via any style or layout flush.
This is a regression from bug 1002992 where we switch from the display list builder to the frame tree walker and didn't update mLastUpdateImagesPos in the frame walker.
Instead do it when we first encounter the root scroll frame.
Doing this goes back to bug 635053, where we did it because fixed position items weren't getting included. However in bug 974643 we learned that this was wrong. Displayports aren't relevant to fixed pos content, displayports are only relevant to scrolled content. And we set the dirty rects of fixed pos content specially. The only other thing that should be affected is scrollbars, and we already carefully set their dirty rects too.
Temporarily rename GetDisplayPort to GetDisplayPortRelativeToScrollPort for the duration of this patchset.
This means that every caller of GetDisplayPort is guaranteed to be touched by this patchset (assuming it compiles), and thus each call site can be checked in review to make sure it is relative to the correct coordinate system.
This also has the side effect of making the computation that takes place in GetDisplayPortFromMarginsData happen relative to the scrollport. As opposed to some things relative to the scroll port, and some things relative to the scroll frame.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name GetOrMaybeCreateDisplayPort.
With APZ we want to be firing scroll events to content more consistently, so
we tie them to the refresh driver tick rather than firing them on paint or
haphazardly on the next spin of the event loop.
Patch by Markus Stange, test fixes by Kartikaya Gupta
