As clip items aren't processed, they have no associated layer entries. This is
a problem when a clip item's underlying frame is the same as one that gets
merged into a container layer, as display-item data will be created, but no
layer entry will be added. This will cause it to be removed on the next
layer-build, and cause a full invalidation.
Fix this by adding an 'mIsMergedFrame' entry to DisplayItemDataEntry and setting
it on all merged frames in BuildContainerLayerFor. This property stops the
entry from being removed when it gets updated.
Since Bug 758620, it's possible for an nsDisplayTransform to appear as the
child of a container layer. This caused problems when it was inactive, as the
invalidation would not be transformed in this case.
Fix this in FrameLayerBuilder by mandating that InvalidateThebesLayerContents
takes the untransformed invalidation and apply the transform in
BuildContainerLayer.
Change GetThebesLayerResolutionForFrame to GetThebesLayerScaleForFrame,
which just returns a scale. Ensure that the scale is as accurate as possible
even if dedicated layers for scrolled content (or any layers at all) have not
been created yet, by taking into account transforms that have not yet
generated layers. This makes the decisions made by
nsGfxScrollFrameInner::ScrollToImpl independent of whether there is
currently an active layer for the scrolled content (or much more nearly so).
In nsGfxScrollFrameInner::ScrollToImpl, do not use the current internal
fractional offset of the ThebesLayer, which is in a mostly unrelated
coordinate space to our scroll positions. Instead, just try to make sure
that the previous and next scroll position differ by a whole number of
layer pixels.
Change GetThebesLayerResolutionForFrame to GetThebesLayerScaleForFrame,
which just returns a scale. Ensure that the scale is as accurate as possible
even if dedicated layers for scrolled content (or any layers at all) have not
been created yet, by taking into account transforms that have not yet
generated layers. This makes the decisions made by
nsGfxScrollFrameInner::ScrollToImpl independent of whether there is
currently an active layer for the scrolled content (or much more nearly so).
In nsGfxScrollFrameInner::ScrollToImpl, do not use the current internal
fractional offset of the ThebesLayer, which is in a mostly unrelated
coordinate space to our scroll positions. Instead, just try to make sure
that the previous and next scroll position differ by a whole number of
layer pixels.
Change GetThebesLayerResolutionForFrame to GetThebesLayerScaleForFrame,
which just returns a scale. Ensure that the scale is as accurate as possible
even if dedicated layers for scrolled content (or any layers at all) have not
been created yet, by taking into account transforms that have not yet
generated layers. This makes the decisions made by
nsGfxScrollFrameInner::ScrollToImpl independent of whether there is
currently an active layer for the scrolled content (or much more nearly so).
In nsGfxScrollFrameInner::ScrollToImpl, do not use the current internal
fractional offset of the ThebesLayer, which is in a mostly unrelated
coordinate space to our scroll positions. Instead, just try to make sure
that the previous and next scroll position differ by a whole number of
layer pixels.
A comment in ApplyThebesLayerInvalidation says that it preserves the content
of ThebesLayerInvalidRegion, in case there are multiple container layers for
the same frame. SetHasContainerLayer, however, immediately clears said property.
This was causing invalidations to be lost since Bug 758620 on fixed-position
elements, as they were being separated out onto their own layers but were still
merged in the root scroll layer. This is tracked in Bug 769541.
This fixes the problem by storing the new invalid region in DisplayItemDataEntry
and clearing/setting the ThebesLayerInvalidRegion property in the
UpdateDisplayItemData callback from FrameLayerBuilder::WillEndTransaction.
