We do the same in FinalizeFrame, so we should do it here.
MozReview-Commit-ID: JTKDj8yrtI2
--HG--
extra : rebase_source : 6ba114c6734990dcb62e361889d1b2cf2b5ad7dc
extra : intermediate-source : 76bf99decf0906f0a6a4ad99539fd40f97c4539f
extra : source : fb9b0524428307c4ee097894e37879339df47579
This commit does the work of actually dispatching the recorded buffer operations
to the paint thread, and removing some main thread asserts from TextureClient.
MozReview-Commit-ID: CN3RoQPz9fP
--HG--
extra : rebase_source : 08ae6cf8445ef0a757efc54175768c2fa9bb1685
extra : intermediate-source : 0fc2414f146d8f5d08c97e5b7eedb25c5632ab2d
extra : source : e9349ad2f1f8fec862b1d2271d0d8f25ad0814d4
This commit adds a CapturedBufferState which is used to record all the operations
that are necessary for preparing the buffers. The commands are then instantly
executed to preserve the same behavior, but in the following commit they will
be dispatched to the paint thread.
Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made
for sending to the paint thread. This complicates the code for AdjustTo as it can
fail naturally and the buffer parameter changes are needed later in BeginPaint.
So the code for AdjustTo is split up a bit to accomodate that.
MozReview-Commit-ID: FwSwFay887o
--HG--
extra : rebase_source : 70dd8a055aaa13586810030978409d1a89c39081
extra : intermediate-source : f235b12eda6efe0bdec8e6590d813738f53ffe82
extra : source : cb6507b560aaad188fc83a47b664aaa5692a0acd
To sync the back buffer with the front buffer, we set the back buffer rect and
rotation to the front buffer's, and then copy over the pixels that different.
We used to do the updating of the rect and rotation before BeginPaint, but that
isn't necessary and we can move it to be with the copying of pixels.
MozReview-Commit-ID: HzBKvMZkn1
--HG--
extra : rebase_source : 053e55df273d0d89327b80bc599ee05a020f6fef
extra : intermediate-source : 467532fd5b7a2385ba0dbdb9201e28e8f2b4a583
extra : source : 3d0da65640964e5a0565b5e7b7646cf719ce1449
This commit is an optimization for double buffering that delays the creation of
a back buffer until we know what kind of content type it needs to be.
Before this commit, we would EnsureBackBufferIfFrontBuffer before BeginPaint,
then in BeginPaint we could determine that we actually needed a different kind
of buffer because the content changed type, and recreate it.
This was needed because BeginPaint would copy the old front buffer to the buffer
created by EnsureBackBufferIfFrontBuffer, and then if anything failed or we had
determined we couldn't reuse the buffer, we would create a new one and copy that
"temporary" back buffer over, and use the new one.
This is unnecessary because we only need read access on that "temporary" back
buffer, and so we can just use the current front buffer instead.
This optimization only affects the double buffered case, and the single buffered
or basic cases should remain the same.
Note: Because we now need the front buffer for copying into the new back buffer,
we cannot Clear() it away in some error cases.
Note: The code in FinalizeFrame assumes that the back and front buffer have the
same size. This was implicitly enforced before, and now needs to be explicitly
enforced. This commit tries to preserve the exact same behavior, although the
restriction should be removed as long as the back buffer is large enough for
the visible region.
MozReview-Commit-ID: 2hyrrUhA4zO
--HG--
extra : rebase_source : 5db62a4d24383c7d64e127880a3bee7ff76dada1
extra : intermediate-source : dce585be0737f3c9b6b241afb0851d85fb9453c9
extra : source : 926af2eca400cf8a16777813ceb586b1d3be7d68
BufferContentType and BufferSizeOkFor make more sense as general functions for
any RotatedBuffer, and this helps out in a later patch.
MozReview-Commit-ID: EAVodvl4WTu
--HG--
extra : rebase_source : 122b6466ef0194d6ff682d677db01312c9e27a2a
extra : intermediate-source : b971c1aa5a78c17d49d1d64389516437024be72a
extra : source : b57a3f0d08478f094328b5a50c57eed35798fdf0
These two tests exercise the codepaths where an event regions override
is set on (a) the root layer of a layer tree and (b) on an in-process
subdocument. I verified that case (b) was failing with webrender enabled
without the patchset and passes now.
MozReview-Commit-ID: Kw6TQjNupSa
--HG--
extra : rebase_source : ce54c46c7d0470b693e82ae3e477b3702155e59d
We now set EventRegionsOverride flags on ref layers only, so
there's no need to have the APIs to set it on container layers in
general.
MozReview-Commit-ID: JKU4UXvdR2e
--HG--
extra : rebase_source : 77f49787e8953520dc56ea4a8f9286b35d6942b8
As with the previous patch, instead of setting the override on the root
layer, we set the flag on the nsDisplayListBuilder before building the
display list, and the flag automatically forces all event regions
display items to use their dispatch-to-content region instead of any
other regions.
Both the WebRender and non-WebRender codepaths were setting the override
flag on their root layers and don't need to any more.
MozReview-Commit-ID: 1cz0ahqwkOm
--HG--
extra : rebase_source : 3292951aca97fd1a355c2fae5b0ab42d2064c548
This code has been unused since the removal of layers-full WR codepaths.
MozReview-Commit-ID: JQn55Kbz5rr
--HG--
extra : rebase_source : af6995265c02a1ddfccbc37adb633bc2b240ec8b
We do the same in FinalizeFrame, so we should do it here.
MozReview-Commit-ID: JTKDj8yrtI2
--HG--
extra : rebase_source : 9f900a4641df71a8da79a406cc89407a3553221f
extra : intermediate-source : de3aa5583481a3680e3d0cfdbe6b55916f0ef58a
extra : source : fb9b0524428307c4ee097894e37879339df47579
This commit does the work of actually dispatching the recorded buffer operations
to the paint thread, and removing some main thread asserts from TextureClient.
MozReview-Commit-ID: CN3RoQPz9fP
--HG--
extra : rebase_source : 9aeb3a727a930638aeb47a45a358769f1338d844
extra : source : e9349ad2f1f8fec862b1d2271d0d8f25ad0814d4
This commit adds a CapturedBufferState which is used to record all the operations
that are necessary for preparing the buffers. The commands are then instantly
executed to preserve the same behavior, but in the following commit they will
be dispatched to the paint thread.
Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made
for sending to the paint thread. This complicates the code for AdjustTo as it can
fail naturally and the buffer parameter changes are needed later in BeginPaint.
So the code for AdjustTo is split up a bit to accomodate that.
MozReview-Commit-ID: FwSwFay887o
--HG--
extra : rebase_source : 376f9a7184bdce2cc405e4608d38b8505aafc2d6
extra : source : cb6507b560aaad188fc83a47b664aaa5692a0acd
To sync the back buffer with the front buffer, we set the back buffer rect and
rotation to the front buffer's, and then copy over the pixels that different.
We used to do the updating of the rect and rotation before BeginPaint, but that
isn't necessary and we can move it to be with the copying of pixels.
MozReview-Commit-ID: HzBKvMZkn1
--HG--
extra : rebase_source : a34e50a4d7664e3134f9da06b10f1908aa0d9d60
extra : source : 3d0da65640964e5a0565b5e7b7646cf719ce1449
This commit is an optimization for double buffering that delays the creation of
a back buffer until we know what kind of content type it needs to be.
Before this commit, we would EnsureBackBufferIfFrontBuffer before BeginPaint,
then in BeginPaint we could determine that we actually needed a different kind
of buffer because the content changed type, and recreate it.
This was needed because BeginPaint would copy the old front buffer to the buffer
created by EnsureBackBufferIfFrontBuffer, and then if anything failed or we had
determined we couldn't reuse the buffer, we would create a new one and copy that
"temporary" back buffer over, and use the new one.
This is unnecessary because we only need read access on that "temporary" back
buffer, and so we can just use the current front buffer instead.
This optimization only affects the double buffered case, and the single buffered
or basic cases should remain the same.
Note: Because we now need the front buffer for copying into the new back buffer,
we cannot Clear() it away in some error cases.
Note: The code in FinalizeFrame assumes that the back and front buffer have the
same size. This was implicitly enforced before, and now needs to be explicitly
enforced. This commit tries to preserve the exact same behavior, although the
restriction should be removed as long as the back buffer is large enough for
the visible region.
MozReview-Commit-ID: 2hyrrUhA4zO
--HG--
extra : rebase_source : 2ddaa7d7d250475cf68524ad2151d8bcc7101013
extra : source : 926af2eca400cf8a16777813ceb586b1d3be7d68
BufferContentType and BufferSizeOkFor make more sense as general functions for
any RotatedBuffer, and this helps out in a later patch.
MozReview-Commit-ID: EAVodvl4WTu
--HG--
extra : rebase_source : 6b3406713414a5fe5c1ace6cd0db86c811557323
extra : source : b57a3f0d08478f094328b5a50c57eed35798fdf0
There are cases where we do a main-thread paint at a scroll position
where sticky offsets have been applied in order to keep sticky items
visually unmoving. From that paint, it's possible to do an async-scroll
in the direction that reduces the sticky offset. In order for WR to
handle this case properly we need to tell WR how much of a sticky offset
was already applied on the main thread.
MozReview-Commit-ID: 79DsfPpsIfA
--HG--
extra : rebase_source : e39316702cff3bd4ee6721c7503a1a9267734cd8
There are up to two compositor threads spawned - one in the GPU process
and one in the UI/chrome process. If the GPU process is used, then
failing to start the UI compositor thread is not fatal -- unless the GPU
process crashes too much and we fallback to the UI/chrome process. If
the GPU process compositor thread failed to start, then the GPU process
will crash and either restart, or fallback to the UI/chrome process
thread. If both fail, then Firefox crashes as expected.
Before we would not setup a content process properly unless the
UI compositor thread was active, even when using the GPU process. Now we
do, which allows the browser to be fully functional. Additionally when
shutting down, we ignore the lack of a compositor thread to permit a
graceful shutdown. In a future patch we will ideally we would not spawn
the compositor thread in a process until we actually need it, and
release assert on its failing to start.
Currently, the device-reset flow doesn't notify the decoder for device change
immediately. The decoder might use an invalid sync-object for synchronization.
Then, we will hit some assertions.
This patch try to make the synchronization flow become fallible, then we could
pass the error to the media framework for error handling.
MozReview-Commit-ID: BFY32MmOdt0
Use MOZ_CRASH, MOZ_CRASH_UNSAFE_OOL, or MOZ_CRASH_UNSAFE_PRINTF instead.
MozReview-Commit-ID: 1kCCHMlgbGP
--HG--
extra : rebase_source : 2f07ced16bccebf30cd3b2b5fea35e9868d32dad
extra : source : 0bf2c8425b828e71de55dd175fd0dad635b4e67d
This is essentially a no-op but it does silence the following warning
whenever the *.pb.* files are re-generated:
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax specified for the proto file: LayerScopePacket.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
MozReview-Commit-ID: 6L1TXHLcjsj
--HG--
extra : rebase_source : c88211414242c921eeefec27476c4a52e6c0974a
Bug 1092294 introduced a regression in to the code to copy from
the discarded front buffers to the new backbuffers in
SingleTiledContentClient. The aim was to ensure that if locking the
the frontbuffers failed, meaning the region could not be copied, that it
would be painted instead. However due to incorrect logic the
region would both be copied and painted in cases where
there was no onWhite buffers.
To fix this we take both locks (frontLock, and frontOnWhiteLock if
required) up front, so that we either copy both buffers or neither.
MozReview-Commit-ID: 3iepOuweruk
--HG--
extra : rebase_source : 2e2f951c3315f2809191f43a9d5ec4a939c82724
This commit does the work of actually dispatching the recorded buffer operations
to the paint thread, and removing some main thread asserts from TextureClient.
MozReview-Commit-ID: CN3RoQPz9fP
--HG--
extra : rebase_source : c14b9da390e88907e184409404c5c21b5fe23dff
This commit adds a CapturedBufferState which is used to record all the operations
that are necessary for preparing the buffers. The commands are then instantly
executed to preserve the same behavior, but in the following commit they will
be dispatched to the paint thread.
Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made
for sending to the paint thread. This complicates the code for AdjustTo as it can
fail naturally and the buffer parameter changes are needed later in BeginPaint.
So the code for AdjustTo is split up a bit to accomodate that.
MozReview-Commit-ID: FwSwFay887o
--HG--
extra : rebase_source : 3e8b49d5931d853857dd1b2eeff914465251f613
To sync the back buffer with the front buffer, we set the back buffer rect and
rotation to the front buffer's, and then copy over the pixels that different.
We used to do the updating of the rect and rotation before BeginPaint, but that
isn't necessary and we can move it to be with the copying of pixels.
MozReview-Commit-ID: HzBKvMZkn1
--HG--
extra : rebase_source : b5f5a0c46c225b8d2fbdd1891a16f3c0812382eb
This commit is an optimization for double buffering that delays the creation of
a back buffer until we know what kind of content type it needs to be.
Before this commit, we would EnsureBackBufferIfFrontBuffer before BeginPaint,
then in BeginPaint we could determine that we actually needed a different kind
of buffer because the content changed type, and recreate it.
This was needed because BeginPaint would copy the old front buffer to the buffer
created by EnsureBackBufferIfFrontBuffer, and then if anything failed or we had
determined we couldn't reuse the buffer, we would create a new one and copy that
"temporary" back buffer over, and use the new one.
This is unnecessary because we only need read access on that "temporary" back
buffer, and so we can just use the current front buffer instead.
This optimization only affects the double buffered case, and the single buffered
or basic cases should remain the same.
Note: Because we now need the front buffer for copying into the new back buffer,
we cannot Clear() it away in some error cases.
MozReview-Commit-ID: 2hyrrUhA4zO
--HG--
extra : rebase_source : 8eb7f992758d2e1db47eb88fe8d31651b335be6d
BufferContentType and BufferSizeOkFor make more sense as general functions for
any RotatedBuffer, and this helps out in a later patch.
MozReview-Commit-ID: EAVodvl4WTu
--HG--
extra : rebase_source : 22c004e81257bf2d31438972c17b7b4f61532b23
The following commits added the necessary tracking to ensure we always end
a profiler marker when we start one, and this just plugs them in.
MozReview-Commit-ID: C5VXpnlH2QA
--HG--
extra : rebase_source : 832c8abdef45e0a9bbb71bbf105fe4a76d0eb60d
This commit adds instrumentation and some asserting to track a "paint group",
which is essentially the first PaintThread::AsyncPaintContents until
PaintThread::AsyncEndLayerTransaction.
I didn't add an AsyncBeginLayerTransaction and use that to start a "paint group"
as I think it makes sense to not have a paint marker if we don't do
any painting.
MozReview-Commit-ID: AlSsUUF5ZOH
--HG--
extra : rebase_source : 84d9feaf5aac39fb9ce32984efda704fa2a68838
I believe this is the only case where we miss calling EndLayerTransaction,
but still had queued async paints. This wasn't an issue before, because
the following transaction would then do the synchronization. But I'd
like to use EndLayerTransaction for a profiler mark, so we should call
it unconditionally.
MozReview-Commit-ID: 9rUXBzCZaLO
--HG--
extra : rebase_source : ba360f2451190cf38745121d4dc32f4ed8d1bfe2
And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
Even if we cannot reuse the back buffer, we still use it to initialize the new back buffer.
The correct condition for detecting changes to buffer mode should only care if there is a
buffer, not if we decided to reuse it.
If the buffer mode has changed to component alpha, we need to invalidate and repaint everything
because we won't be able to copy over content to the new buffer correctly.
I believe this is a regression from the refactoring that created this function from
RotatedContentBuffer::BeginPaint.
MozReview-Commit-ID: H9G7GxqekLt
--HG--
extra : rebase_source : afb3321694ce3f1b54ad4dce28b4a7c7c7b47904
extra : amend_source : fdef1994514fcc9b9f2e952767a785841e9ddda0
extra : histedit_source : 3e8324255f516094c242ab3ec0688d2285c85a99
Add a new TextureClientData type, AndroidNativeWindowTextureData,
backed by a SurfaceTexture in single-buffer mode. It uses the
NativeWindow API, which provides producer-side access to the buffer.
This provides a DrawTarget which can be used to paint directly in to
the SurfaceTexture, which can then be composited using a SurfaceTextureHost.
Due to API restrictions it is not possible to read from a NativeWindow
while the corresponding SurfaceTexture has ownership of the
buffer. TiledContentClient now handles that by painting the additional
region that it cannot copy from the front buffer, if required.
MozReview-Commit-ID: 1NZq6MQqwFq
--HG--
extra : rebase_source : 9d1db721d4892f3df033d43127489a85421e8863
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "// \* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
####
old="// \* This Source Code Form is subject to the terms of the Mozilla Public"
new=" \* This Source Code Form is subject to the terms of the Mozilla Public"
sed -i s%"^$old"%"$new"% $1
####
MozReview-Commit-ID: Ihx0EAOkT2g
--HG--
extra : rebase_source : 4dc97f234495e3ec1f4904e91d43d00fd3810626
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "^\* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
line1="\* This Source Code Form is subject to the terms of the Mozilla Public"
line2="\* License, v\. 2\.0\. If a copy of the MPL was not distributed with this"
line3="\* file, You can obtain one at http://mozilla\.org/MPL/2\.0/\. \*/"
# Insert 1 space at beginning:
sed -i s%"^$line1"%" $line1"% $1
sed -i s%"^$line2"%" $line2"% $1
sed -i s%"^$line3"%" $line3"% $1
###
MozReview-Commit-ID: HXBMrfnhlVr
--HG--
extra : rebase_source : de4c78563711f8366e2978c5199a5041875fbe38
This patch doesn't modify the mode lines at all -- it just swaps their order,
and makes each one its own C++ comment, separate from the MPL boilerplate
comment.
MozReview-Commit-ID: BEZJVj2sMuK
--HG--
extra : rebase_source : 9e0946c8a8d0b67c11b5932b9d1e51e0e6e8ebef
These items don't paint anything and are handled separately, so we don't need
to call CreateWebRenderCommands for them. We could just implement
CreateWebRenderCommands for the item and have it return true unconditionally,
but it's still an extra virtual call. Plus there's existing code in
WebRenderCommandBuilder that's conditioned specifically for event regions so
I prefer keeping all the conditioned code together.
MozReview-Commit-ID: 5kTuv7qgiKU
--HG--
extra : rebase_source : 8bd1a3fdf6711d06ff7523a25324da3a170215a3
This changes the serialization format a little bit.
We now have an index at the end of the blob. This
is currently used to store a list of the used font keys.
In the future we'll add rects and can use it for invalidation.
This extends the fix in bug 1373802 to account for extra levels of
display item nesting. If those extra intermediate display items don't
push any clips we still want to pick up the ClipAndScroll from the
enclosing ancestor that has it.
MozReview-Commit-ID: AmxRz4fBKnX
--HG--
extra : rebase_source : ae12a9f797ab201169ff199d0d42a29df51ee1cb
We already support cases where we have scrolling clips applied to fixed
items. However if we had to build nested clips inside those items, then
those nested clips would not properly inherit from the scrolling clips.
This patch addresses that case.
MozReview-Commit-ID: CWp1x0EsyaP
--HG--
extra : rebase_source : f8c80ace2da39edebaabd5339670a68038a18489
The window buttons are drawn as part of the AddWindowOverlayWebRenderCommands
function which is invoked in the full-transaction codepath. It should be possible
to have the empty transaction codepath simply update the image (without building
a full WR display list) and do a recomposite. That would be more performant but
it requires some plumbing to build and ship across a IpcResourceUpdateQueue on
empty transactions.
MozReview-Commit-ID: 2Mrb0wELD6E
--HG--
extra : rebase_source : 9a94c32f94403050835bf3445176f4fe2c1579fa
This is functionally unrelated to the bug but I noticed it while fiddling with
the code, and the lines affected are kind of intertwined with the next patch so
I'm just doing the code removal as part of this bug.
MozReview-Commit-ID: CwmluhyCdbR
--HG--
extra : rebase_source : 0a86ba7299f63587b77c44fadc804e34ada5a474
We want to always use Servo animation backend on the compositor.
However, Android doesn't support Stylo now, so add a defined flag for it.
MozReview-Commit-ID: 63MnTBnq6yv
--HG--
extra : rebase_source : dce46737f81e4e217e9fd67b6bec722994dca6a2
Use the new added FFI, Servo_ComposeAnimationSegment, to compose an
animation segment from Servo backend on the compositor.
MozReview-Commit-ID: LNgpCSIlDl9
--HG--
extra : rebase_source : 5b5c145fae877b4f4b01ea54259737dc9dad2951
We will use Servo backend on the compositor, so implement this for opacity.
MozReview-Commit-ID: BeWR2nBSbjb
--HG--
extra : rebase_source : eb5db3cf04640a83f13857984e792a949f26bcc7
My original understanding of the API was flawed, and so while I had
position:sticky working in some cases it didn't work properly in a lot
of other cases. This patch corrects the usage of the API to match what
WR is expecting and fixes a lot of test cases.
MozReview-Commit-ID: AdMux19Fk9U
--HG--
extra : rebase_source : e7f970a710b2079501a91eeeac8c292b603210dc
Most of this change is just fiddling with function signatures so that they take
a LayerManager* instead of a Layer* (or in some cases, both). This allows
the WebRender codepaths to pass a WebRenderLayerManager* instead of having to
produce a Layer* which it doesn't have.
MozReview-Commit-ID: Fb0C8OUVDin
--HG--
extra : rebase_source : e4c3324cfa20c295db85d5c09df8d8d77865bb6a
Instead of unconditionally pushing and popping clips per display item,
this patch changes things so that for each recursive display list, we
create an ItemClips struct. We push this onto the stack when we enter
the display list, and pop it off at the end. For each display item, we
check to see if the clips would actually change compared to the previous
display item, and only do the pop/repush in that case.
MozReview-Commit-ID: J0MCc2V9hWT
--HG--
extra : rebase_source : 8617cfaa7391457867f01c1b619cb871a21bf3f5
This makes ScrollingLayersHelper a non-RAII type class, and instead adds
methods to notify it of when we start processing a new transaction or a
new display item within the transaction. This patch has no functional
changes, it's non-obvious refactoring.
MozReview-Commit-ID: GEZzCGbVqB1
--HG--
extra : rebase_source : dd4fab7f34da7c5465ba474db670cf583e8dadf4
Storing the per-item clip state in a struct like this will allow us to
easily compare the desired clip state across items, so we can avoid
doing unnecessary work when going from one item to the next. This patch
has no functional changes, it's just refactoring.
MozReview-Commit-ID: GX2FX4YDusO
--HG--
extra : rebase_source : 06d7bae5cbae99d2987881f26f7ebd26965c1799
Instead just keep a ref to it as a member variable. No functional
change.
MozReview-Commit-ID: 9jSBdZRIGuV
--HG--
extra : rebase_source : cd1b2f500e9a833f7d42bce53bdaec2118e0d4c3
Instead of unconditionally pushing and popping clips per display item,
this patch changes things so that for each recursive display list, we
create an ItemClips struct. We push this onto the stack when we enter
the display list, and pop it off at the end. For each display item, we
check to see if the clips would actually change compared to the previous
display item, and only do the pop/repush in that case.
MozReview-Commit-ID: GadIp2J8TrA
--HG--
extra : rebase_source : ba64c6b4659b8e51cab19b807088b9a50d71b85a
This makes ScrollingLayersHelper a non-RAII type class, and instead adds
methods to notify it of when we start processing a new transaction or a
new display item within the transaction. This patch has no functional
changes, it's non-obvious refactoring.
MozReview-Commit-ID: 3yq9sPiHMge
--HG--
extra : rebase_source : 286423f56de59211e320f015cb1004a1e98332b8
Storing the per-item clip state in a struct like this will allow us to
easily compare the desired clip state across items, so we can avoid
doing unnecessary work when going from one item to the next. This patch
has no functional changes, it's just refactoring.
MozReview-Commit-ID: 49B6hmsWZ4V
--HG--
extra : rebase_source : 8ac4bbf039f81bc2d26e92924ed041fa3d18e5ba
Instead just keep a ref to it as a member variable. No functional
change.
MozReview-Commit-ID: 5fccUlSifsA
--HG--
extra : rebase_source : a14672f926c383354db76e553ae23613fe4a432a
One of the sticky-pos tests was only passing because of two wrongs that
cancelled each other out in the old code. Specifically, instead of
defining a nested clip with the sticky clip as an ancestor, the clip was being
defined with the root ASR as an ancestor. Both resulted in the nested
clip not scrolling with the actual scrolling scrollframe and so the test
was passing.
The new code changes things so that the nested clip is defined with the
actual scrolling scrollframe as the ancestor, causing the reftest to fail.
Fixing the clip ancestry is not hard but it reveals other problems so
so I'm deferring that to a follow-up bug.
MozReview-Commit-ID: DldAKi1AP4l
--HG--
extra : rebase_source : a448e06fd26fff21bbc4a6f50e04dbbdb427298c
This handles some cases where a nested display item's clip chain
implicitly extends from the wrapper item's clip chain.
MozReview-Commit-ID: DmghxOWi81K
--HG--
extra : rebase_source : 8ec95df64fed247650baf8f5e0c868d1934aa6bc
Bug 1409442 is tracking a change that will allow scroll layers to have
multiple ancestors. Without that, there are cases we cannot properly
handle, and so we need to ignore a clip in those scenarios. This patch
makes sure we do that instead of crashing.
MozReview-Commit-ID: 7AU4uyzT6if
--HG--
extra : rebase_source : d483c2a7ecff5cd488a53fa5e6b6da55cc3a1e29
When display items (such as mask items) push an out-of-band clip, we
can't use clip ids from, or update clip ids into, the cache. We also
need to ensure we take these out-of-band clips into account when
determining the parent for a new clip we are going to define.
MozReview-Commit-ID: GcUI2Hf6SLB
--HG--
extra : rebase_source : 512be5a6998b9c1d6db9d8c550231f0883d721c9
This code is more straightforward in its recursion than the old code,
and provides a relatively clean way to explicitly pass the desired
parent when defining a new clip or scroll layer.
Refer to the documentation in the patch for more details.
Note that this patch provides the basic recursive algorithm to define
the clips and scroll layers, although it omits some of the complicating
edge cases which will be added in later patches. The new code is not
invoked from anywhere until all the edge case handling has been done.
MozReview-Commit-ID: 7z51Kd7LlPU
--HG--
extra : rebase_source : 491efac9282a7379f7977a1bc0205ac70e356c3c
The APIs now allow providing the parent clip or scroll info explicitly
instead of having to push it on the stack. For now we just pass
Nothing() to preserve the existing behaviour, so this change is a
functinoal no-op.
MozReview-Commit-ID: dtNamN595
--HG--
extra : rebase_source : 3b6bd03b919bd31cd89e3f82283cb962f8f6abc5
sotaro
Kartikaya Gupta
Ryan Hunt
Andreea Pavel
Mats Palmgren
David Anderson
vincentliu
Lee Salzman
Andrew Osmond
James Willcox
Ethan Lin
JerryShih
Chris Peterson
NARCIS BELEUZU
Francois Marier
Jamie Nicol
Phil Ringnalda
Daosheng Mu
Csoregi Natalia
Sebastian Hengst
Attila Craciun
Jeff Gilbert
Daniel Holbert
Coroiu Cristina
Jeff Muizelaar
Boris Chiou