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 : 5aafcb5496e3d60aea705768c28836267f848ec8
RecomputeVisibilityForItems for the retained ThebesLayer already recomputes
visibility for all items in that layer, including items nested in other items.
--HG--
extra : rebase_source : f729f754da18d7ce67577fc5b3ca065f2103e218
It is no longer called because FrameLayerBuilder always sets the visible
regions on layers now.
--HG--
extra : rebase_source : e5a4d2985c055b3d53137e0bb4822961dbf57408
We need this to avoid constructing and painting unncecessarily large
ThebesLayers.
--HG--
extra : rebase_source : fd56072f7932fa9c39f314c4d95cdd0d1ad13de3
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 : 5931e3462734983134193b766410593288afc296
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 : 7748dde5aa0d51573acec9eb163f864beabefb3b
The removed code should be a no-op as long as the window opaque region is
accurate enough.
--HG--
extra : rebase_source : ecdfdbd02fdf8df23a71514ada32a8d20926913f
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 : 8ac6abb8f6b3ab078883935688ae1f5059b797c7
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 : 26e5e44fa90000089f1dc64c1cb073d5b1806765
BuildContainerLayerFor now has to be able to mutate the passed-in display item
list.
--HG--
extra : rebase_source : c242006445d90372f6c7941d909f30945422321b
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 : 52cf25ce39a6ab38f89e0231ea044fdf3cac0a2d
Also the assertion in TryMerge is going away because we're going to do TryMerge
first in FrameLayerBuilder.
--HG--
extra : rebase_source : 62594931ff461dc1ae2c744531252d2b3c696ca0
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 : 29c7b2a43f4cb67b4c778851b18dba3e3e2ebd3d
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 : d846866a6128bb96903e45e6bd08ef67033bf701
