We currently set the visible region on most container layers twice: once in
BuildContainerLayerFor, where we don't take clipping from ancestors into
account, and then later ProcessDisplayItems calls RestrictVisibleRegionForLayer
which does take ancestor clipping into account. This causes unnecessary
Mutated()s.
In this patch we partially fix this by forcing transform layers to take
account of their ancestor clipping when they set the visible region in
BuildContainerLayerFor. For those layers we don't need to apply
ancestor clipping in ProcessDisplayItems. This is done in a rather
ugly way, by passing the ancestor clip rect as an extra field of
ContainerParameters. To preserve the optimization that prerendered
elements are treated as fully visible regardless of ancestor clipping,
we have to add a flag to turn that clipping off in BuildContainerLayerFor.
In bug 841192 we will be able to fix this in a much nicer way, because we can
get the ancestor clip directly off the nsDisplayItem passed to
BuildContainerLayerFor. But this approach is needed for the B2G18 branch.
--HG--
extra : rebase_source : 26fbe55db84ab96e1e358b8803b0563f42590836
Except for the changes in:
layout/generic/nsIFrame.h (part)
layout/style/nsComputedDOMStyle.h (all)
layout/style/nsRuleNode.cpp (part)
layout/style/nsStyleContext.cpp (part)
layout/style/nsStyleContext.h (part)
(see patch 3b in the bug), this patch was written with the sed script:
s/\<GetStyle\(Font\|Color\|List\|Text\|Visibility\|Quotes\|UserInterface\|TableBorder\|SVG\|Background\|Position\|TextReset\|Display\|Content\|UIReset\|Table\|Margin\|Padding\|Border\|Outline\|XUL\|SVGReset\|Column\)\>/Style\1/g
Previous patches in this bug enabled the nsDisplayCanvasBackground
background-caching optimization for the test 402807-1.html. That exposed
an existing bug where we don't snap the background image to pixel
boundaries when drawing through that path. This patch fixes it.
This patch also stops the IsSingleFixedPositionImage path from using
mDestRect, returning the rect as an out-parameter instead.
--HG--
extra : rebase_source : b7a496dfc7584dd8c73cddd0809fc5aa31992d53
Renames GetList to GetSameCoordinateSystemChildren, and adds an assertion
to verify that the children have the same reference frame as the parent.
Adds nsDisplayList::GetChildren to return whatever children there are.
Obsoletes nsDisplayTransform::GetStoredList.
If there is a plugin in a background tab and a complex scene in a foreground tab the accurate visible regions can cause us to bog down, for no good reason.
Updating plugin widget geometry every time we paint means we don't have to
explicitly request plugin geometry updates.
This patch stops us from flushing plugin geometry changes in
FlushPendingNotifications(Flush_Layout). There are too many Flush_Layouts and
flushing plugin geometry changes on them produces frequent
desynchronization of the plugin geometry with the rendered window contents.
There is some Web compatibility risk there --- it means we have to change
our tests, for one thing --- but hopefully it's OK.
--HG--
extra : rebase_source : 87adde45795ea2cab362ed9df54e62c5cc97e16c
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.
The underlying frame of an nsDisplayScrollLayer can change and end up returning
different values when finding the active scrolled root. Instead of relying on
display-item ordering/merging, get the scrolled frame from the item (which was
already storing it).
Allow nsDisplayFixedPosition items that share the same fixed-pos frame to be
merged. This avoids a bug where the Google PDF viewer document image gets
re-rendered offset on the initial frame of a scroll when layer acceleration is
enabled.
Positioned descendants of positioned frames escape the child display list to
their parent's positioned descendants list when they don't have a z-index set.
This caused their invalidations to be logged against the incorrect layer.
To fix this, wrap each extra positioned descendant of a fixed-position frame
in its own nsDisplayFixedPosition so they receive their own layers.
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.
Introduce a new display-list item 'nsDisplayFixedPosition' that represents
fixed-position elements. This item cannot be merged, which forces fixed
position elements to have their own layer, and has a BuildLayer implementation
that sets the necessary metadata on a Layer to be able to maintain its
position correctly during composition when asynchronously panning and zooming.
Introduce a new display-list item 'nsDisplayFixedPosition' that represents
fixed-position elements. This item cannot be merged, which forces fixed
position elements to have their own layer, and has a BuildLayer implementation
that sets the necessary metadata on a Layer to be able to maintain its
position correctly during composition when asynchronously panning and zooming.
* * *
Bug 539356 - Part 9a - Add new display list invalidation API to nsDisplayItem and implement it. r=roc
* * *
Bug 539356 - Part 9b - Add new frame invalidation API. r=roc
* * *
Bug 539356 - Part 9c - Remove old invalidation code. r=bz
* * *
Bug 539356 - Part 9d - Make SVG support the new invalidation model. r=jwatt
* * *
Bug 539356 - Part 9e - FrameLayerBuilder changes for display list invalidation. r=roc
* * *
Bug 539356 - Part 9f - Compute the invalid area of the layer tree and pass this to the widget. r=roc
* * *
Bug 539356 - Part 9g - Modify MozAfterPaint code to work with the new invalidation model. r=roc
Currently we return an extra out parameter on GetOpaqueRegion. This is ugly and it's also going to be inefficient
because in a followup patch I'm going to avoid calls to GetOpaqueRegion, but we still need to know whether the item
needs a transparent surface. So this patch removes that out parameter. Instead, we rely on the fact that only
Windows' glass-window-background display item needs to force a transparent surface, and there can only be one
of those per window. So we store a reference to it in the nsDisplayListBuilder if there is one, and then we can
efficiently tell if any leaf display item is the one that forces a transparent surface. For display items that
wrap a list, we continue to store whether they need to force a transparent surface in a boolean in the list.
It turns out that calling HasBorder() is especially expensive for themed frames since we call into the theme engine to compute the border, so avoiding it is a nice win.
It turns out that calling HasBorder() is especially expensive for themed frames since we call into the theme engine to compute the border, so avoiding it is a nice win.
Previously we snapped the results of nsDisplayItem::GetBounds and
nsDisplayItem::GetOpaqueRegion internally. By tracking which display items were
inside transforms, we disabled snapping quite conservatively whenever an ancestor
had a transform, which is undesirable.
With this patch, we don't snap inside GetBounds or GetOpaqueRegion, but just return
a boolean flag indicating whether the item will draw with snapping or not. This flag
is conservative so that "true" means we will snap (if the graphics context has a transform
that allows snapping), but "false" means we might or might not snap (so it's always safe
to return false).
FrameLayerBuilder takes over responsibility for snapping item bounds. When it converts
display item bounds to layer pixel coordinates, it checks the snap flag returned from
the display item and checks whether the transform when we draw into the layer will be
a known scale (the ContainerParameters scale factors) plus integer translation. If both
are true, we snap the item bounds when converting to layer pixel coordinates. With
this approach, we can snap item bounds even when the items have ancestors with active
transforms.
