D2D repeating gradients rasterize slightly differently to non-repeating gradients even when
the rendered area falls within a single tile, so a repeating gradient compared to a
non-repeating gradient (say one drawn in a canvas) can cause reftest failures.
If we always align the new scroll position with the previous scroll position, we can accumulate error and
gradually drift out of alignment with the layer pixels until we exceed the tolerance and are forced to
rerender everything.
Add a test that makes sure that scrolling a page with a fixed background
doesn't cause that background to repaint.
--HG--
rename : layout/reftests/backgrounds/blue-32x32.png => layout/base/tests/chrome/blue-32x32.png
Fix the size check in nsDisplayBackground::ShouldFixToViewport so that async
scrolling of fixed backgrounds works correctly when zoomed in on Firefox
Mobile. Also make IsFixedItem in nsDisplayList public and use it in
FrameLayerBuilder, so that fixed items are determined and treated consistently.
Separate out background layers into separate display-list items, so that
backgrounds that are a mix of fixed and non-fixed layers will be treated
individually.
This test chokes on the changes in the patch for some reason. Fortunately, since
enablePrivilege now exists solely to make our tests go green, changing its semantics
and removing use of it from anywhere that goes orange is a perfectly acceptable
approach. ;-)
This test chokes on the changes in the patch for some reason. Fortunately, since
enablePrivilege now exists solely to make our tests go green, changing its semantics
and removing use of it from anywhere that goes orange is a perfectly acceptable
approach. ;-)
This propagates the non-inherited (in the nsChangeHint sense, not the
CSS inheritance sense) parts of the parent's change hint through
ReResolveStyleContext so that we can use them in
nsStyleContext::CalcDifference. In the cases where we don't know the
parent's hint, we assume the worst, that all the non-inherited hints
were present in the parent's style change.
This should be a significant performance improvement handling simple
style changes (such as a style attribute change setting a non-inherited
property) on elements with large numbers of descendants that have data
in ForceCompare structs that can't be stored in the rule tree (for
example, margins or widths in em or rem units).
This is in preparation for adding an additional caller.
nsChangeHint_NonInherited_Hints will be reintroduced in patch 6, but as
the maximum set of such hints rather than the minimal set, and with the
less confusing name nsChangeHint_Hints_NotHandledForDescendants.
This test chokes on the changes in the patch for some reason. Fortunately, since
enablePrivilege now exists solely to make our tests go green, changing its semantics
and removing use of it from anywhere that goes orange is a perfectly acceptable
approach. ;-)
