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 : c735f4cb964d659b6778f5b43fa2e2b4c8f83933
RecomputeVisibilityForItems for the retained ThebesLayer already recomputes
visibility for all items in that layer, including items nested in other items.
--HG--
extra : rebase_source : df909f3a9d6eabdb3d83a7770d090068ecca2686
It is no longer called because FrameLayerBuilder always sets the visible
regions on layers now.
--HG--
extra : rebase_source : 6157f9e4a6822598242f6fc9c0abaf07258613d6
We need this to avoid constructing and painting unncecessarily large
ThebesLayers.
--HG--
extra : rebase_source : 38cbd0b0dd7724cfdb98f3e215bd0f220a687f3c
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 : dc1eaa8079f61648c24ac9502e837ac9f2630730
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 : 2534f87eec88d5eba40726032e74ce85ac13be64
The removed code should be a no-op as long as the window opaque region is
accurate enough.
--HG--
extra : rebase_source : c48e2ecaa9e7653708681011cd335d377d5bfaba
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 : dc8bbdd564cc99df1286921e59642648779b9c4a
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 : 43dced732123617f85f360d13861b01d70fddef5
BuildContainerLayerFor now has to be able to mutate the passed-in display item
list.
--HG--
extra : rebase_source : 6a9727998a5ffb01896a4a2bbdd8d30a24c89dcd
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 : 9c94f2091818bb50b31a584a53c572007cd6d0e6
Also the assertion in TryMerge is going away because we're going to do TryMerge
first in FrameLayerBuilder.
--HG--
extra : rebase_source : d6343f0a7cb26f9848c2d2b8d46bb1787d3ae632
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 : 5e07ef9e894ef41d36d4daf4498a14d5163da337
