One nice bit of fallout from this bug is that handling plugin background
readback is simplified. We no longer have to fiddle with display item
visibility calculations; only layer occlusion culling has to know about
readback.
--HG--
extra : rebase_source : 0f389e66354c6e345311da01b739a81ced73d699
RecomputeVisibilityForItems for the retained ThebesLayer already recomputes
visibility for all items in that layer, including items nested in other items.
--HG--
extra : rebase_source : 5549164408aef7bcb3fb9204b1d6b96476d3f675
It is no longer called because FrameLayerBuilder always sets the visible
regions on layers now.
--HG--
extra : rebase_source : b6c375fbbaeb79e7332cb55bdda9943bc1ee7f3c
We need this to avoid constructing and painting unncecessarily large
ThebesLayers.
--HG--
extra : rebase_source : 22b1fbbd8b561bd68831ac1fb957d2d1901f3297
Calling Layer::SetVisibleRegion multiple times in a transaction can result in
unnecessary IPC traffic.
This patch removes Intersect(childGfxBounds). This is only needed to
restrict the visible region to something sane for 3D transforms, and this will
be fixed up in a later patch.
--HG--
extra : rebase_source : 4518bc060fa2c28dacdb7d3aaeca55a148dfe762
Prior to this patch, the only tests that caught this were a couple of obscure
cases on B2G. This test tests it on all platforms.
--HG--
extra : rebase_source : b4bb464bab59dd1d8c5e6b8aa4402d040105b27d
The removed code should be a no-op as long as the window opaque region is
accurate enough.
--HG--
extra : rebase_source : 7486f406da1f01ca13bb903c2a171e68da8aa6ab
Computing this via FrameLayerBuilder is some work and we don't really have to.
SuppressComponentAlpha will be true in more cases. This will be OK as long as
text in the chrome window is over opaque content in the same ThebesLayer. We
will miss some edge cases such as text in 'opacity' with no opaque background.
This should be OK.
--HG--
extra : rebase_source : fa23d4980710a3961f23cedf3ebdf01b49d63518
This is less general than what nsDisplayItem::ComputeVisibility does. This means
if multiple opaque items together cover the list bounds, but not individually,
we won't mark the list as opaque. I think that should be OK.
--HG--
extra : rebase_source : 947fe7bfe8729703ebd46288dfa29f0935fadf87
BuildContainerLayerFor now has to be able to mutate the passed-in display item
list.
--HG--
extra : rebase_source : a3cf9106703d4946a49a73ef60a605f72b2afee3
Getting the timing of this right without processing display items in reverse
order is hard. But it doesn't matter if this property sticks around anyway.
--HG--
extra : rebase_source : a5a68cc0184209506b5c842bf3c5b90648aae159
Also the assertion in TryMerge is going away because we're going to do TryMerge
first in FrameLayerBuilder.
--HG--
extra : rebase_source : de8a1a620279182bf5e33165aa9bbe9a74c08a73
When printing, every page has the same origin. So doing this change naively
would result in the first page having all the display items for every page
added to it, and all but the first page's display items being pruned
away by PruneDisplayListForExtraPage. This would making printing long documents
very slow. We avoid that problem with the new check for
NS_FRAME_FORCE_DISPLAY_LIST_DESCEND_INTO, so the only pages other than the
current page we descend into are the ones with placeholders for abs-pos content
on the current page.
--HG--
extra : rebase_source : b9b8c53d5ad5e4eb2d3c5e1f407d605558b3b9d0
We need this to set the initial visible rect during display list construction.
Eventually we'll also be able to get rid of the dirty rect parameter to
nsIFrame::BuildDisplayList.
--HG--
extra : rebase_source : b793c7d51917b85ea2a5f39993bc1fec24b49d04
This is similar to bug 1038488, which did the same for style structs.
This means the entire path from frame to style struct should be
allocated using frame IDs or object IDs.
