Since fixed position elements are now scrollable, we need to ensure that they're
drawn using the layout viewport size instead of only the SPC-SPS, since
otherwise they'd be inaccurately clipped when scrolled.
MozReview-Commit-ID: 4p3pWnwluvz
--HG--
extra : rebase_source : f5bc1eae9bf2c8f4b9f78675e9da071de012160e
Effectively we compute the diff by lopping off the rounded part
of each rect where appropriate. This gets a bit weird to think
about with very mismatched radii, but I think it works out(?)
MozReview-Commit-ID: 472gx7Hw1Br
--HG--
extra : rebase_source : 817a84d78c98ac99797ab73b89f8c667189767d1
I've tried to unsuccessfully reproduce the same kind of failures locally under
rr with this patch applied, so that's a good sign.
This should fix the case where we don't invalidate from AttemptPartialUpdate
while trying to sync-decode.
This is a clear part of the problem, though not sure yet if it'll fix all the
issues we see in these tests. In any case I want to investigate those
separately.
Differential Revision: https://phabricator.services.mozilla.com/D2068
MozReview-Commit-ID: H7OEvbQUues
In some cases we get a gecko display list that looks like this:
WrapList with asr(<A>, <B>)
Item with asr (<B>) and clipchain(<something> [A])
In this case, we would initialize the WebRenderLayerScrollData for the
nested item using a stop-at ancestor of A (because that was the leafmost
ASR from the containing WrapList) but the item itself has an ASR of B,
which is an ancestor of A. So when walking up from B we'd never hit the
stop-at ancestor, and so we'd end up duplicating metrics from the
containing WRLSD onto the nested WRLSD. This generated an assertion
failure in the APZ code.
This patch detects this scenario and skips adding metrics on the nested
WRLSD. This produces an APZ tree equivalent to what the non-WebRender
path would produce.
MozReview-Commit-ID: 8eo6pzXXKBd
--HG--
extra : rebase_source : 0581c54c4d9fa6ca08249e42b306c7155022bec7
It's causing cache misses which are showing up in profiles of the displaylist
mutate test case.
To avoid checking Disconnected(), we can destroy the DisplayItemData
and unset the item's pointer to it, rather than calling Disconnect()
in the first place.
To avoid fetching the LayerManager (to compare with mRetainingManager)
we can store this value on the display item along with the
DisplayItemData.
This change ensures that if a nsDisplayItem holds a pointer to a
DisplayItemData then that DisplayItemData holds a pointer back, and
vice-versa.
MozReview-Commit-ID: AAVAs8c0CQY
--HG--
extra : rebase_source : e60c378877618592f311e690219099b1cfc4c9d4
This gets set to a non-zero value when we have an inactive ContainerLayer ancestor (filter in this case).
The current code assumes we'd never call BuildLayer on an image when that happen, but we force the pseudo-active
state here because background-position is animated (all properties have a transition).
MozReview-Commit-ID: 6pL8EJTNgWy
--HG--
extra : rebase_source : 6370fc79d5f47f0b5c4bbe86c0b605b90256b653
In the case of an invalid clip-path, the browser is supposed to discard the
mask entirely. In the non-webrender codepath this would happen
implicitly because the computed MaskUsage would have no flags set, and
so no actions would be taken on the gfxContext which contained the
display items rasterized so far. In the WebRender codepath, though, we
invoke the code on a A8 drawtarget that's zero-filled, so if PaintMask
fails to rasterize anything into it, it gets treated as a "mask everything
out" mask. Instead, this patch makes it so that we detect the scenario
where the computed MaskUsage is a no-op, and ensure that we don't apply
the mask in that case.
An alternative approach considered was to initialize the A8 drawtarget to
white instead of black but in cases where there is an actual mask, the
rest of the code assumes it is zero-filled and so that doesn't work.
MozReview-Commit-ID: Hw7nCiUXVJl
--HG--
extra : rebase_source : 241d550fa0ed1b3bd088c73d9565b166acbcece8
This allows us to call emplace_back, saving us a move.
MozReview-Commit-ID: 4wRiAxl7LSN
--HG--
extra : rebase_source : 0ea07c896c2807a65ad7493a22b8e2b61e68aa01
This allows us to call emplace_back, saving us a move.
MozReview-Commit-ID: 4wRiAxl7LSN
--HG--
extra : rebase_source : 48a0eee8f61f568e0910476dbf672cb43827187e
This call was added in bug 929362, but the key factor to fix the bug was just
setting a flag representing that the target frame doesn't allow the animation
running on the compositor and checking the flag in the function whether the
animation can be run on the compositor or not in later ticks. So the call
wasn't necessary in the first place.
The test case here fails without this fix. The test case actually doesn't
observe animation restyle count at all, so it might look a bit awkward in
file_restyles.html, if we add other test cases checking SchedulePaint calls
in future, we will move the tests in a different file.
(The reason there is no animation restyles in this case is that we properly
throttle the animation in this case.)
MozReview-Commit-ID: AyHciRJHM0s
--HG--
extra : rebase_source : f3963336ea9165b0a9c1a662bdac5c645b209219
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
