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 IPC is no longer used and can be removed to simplify
the PVRManager protocol.
MozReview-Commit-ID: Kno5CHkI17K
--HG--
extra : rebase_source : 227e36b00bc2d6a3b83b48d80fbfdfe35196057d
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
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
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/\. \*/"
# Strip off 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: EwCjyajgY4W
--HG--
extra : rebase_source : c61ca17ba556290d1f27af0a0c84e2ccc5371a36
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 was mostly[1] automatically generated. I found the files to be fixed
in this patch with the following command:
grep -r "C++; indent-tabs-mode:" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
old="/\* -\*- Mode: C++; indent-tabs-mode: nil; c-basic-offset: 4 -\*- \*/"
new="/\* -\*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -\*- \*/"
sed -i s%"^$old"%"$new"% $1
###
[1] NOTE: Nearly all of these files use 2-space indentation, so it's correct
(from a consistency perspective and a reflecting-reality perspective) that
we're reducing their "c-basic-offset: 4" down to "c-basic-offset: 2" here. The
one exception is nsDeviceContext.h, which *does* actually use 4-space
indentation right now -- so I'm leaving that file with "c-basic-offset: 4" in
its mode line. This manual change (reverting 1 character from the automated
process) is the only piece of this patch that isn't automated.
MozReview-Commit-ID: L4MbyeYSbfY
--HG--
extra : rebase_source : 8ddbe422471bfd8b0060e96fb1c8cd062f10f290
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
- Oculus SDK was updated from 1.5 to 1.9
- As the Oculus API now returns quaternion orientations for each
eye-to-head transform, I needed to send more information to the
content process.
- Rather than adding the quaternion, we now calculate the view matrices
on the VR thread in the GPU process rather than calculating it in the
content thread from parameters.
- OpenVR's full view matrix is now used, for compatibility with more devices.
- IPD adjustments are now updated every frame for both Oculus and OpenVR.
MozReview-Commit-ID: LOtfs4QIqc8
--HG--
extra : rebase_source : 0a69824012ede4bea0e0e709a2d027d0c35730bb
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
The earlier patches in this bug were written before we had
sophisticated binding generation so the types didn't match very well.
This fixes all of that.
MozReview-Commit-ID: DpcblpB8vxW
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
This edge case happens when:
- we have a display item A nested inside another display item B
- B has pushed an out-of-band clip, and
- A's clip chain doesn't connect directly to the end of B's clip chain
but instead connects somewhere farther up the clip chain
See comments in the patch for more details.
MozReview-Commit-ID: 4mCCaVUQuvH
--HG--
extra : rebase_source : 1601a8f0c586d618d395b4e20086b9ecd318945b
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
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 98da45bc7f2eaabd63ae226c505cb1580b5c8500
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
Instead of just keeping a count of how many "extra clips" (aka
out-of-band clips) we have pushed, track more complex information for
each clip. In particular, track the display item's normal clip chain, as
well as the clip id of the extra clip that was pushed. This will be
needed to override clip cache information in the next patch.
MozReview-Commit-ID: AWKDTkelhyL
--HG--
extra : rebase_source : 379e38550cf45d54862850f6c4aad0ac488f6ca9
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
By using a variant we can keep a single stack of both clips and
scrollframes, rather than two separate stacks. This is important because
we will want to know how the things are interleaved (e.g. if the last
thing that was pushed was a clip or a scrollframe).
MozReview-Commit-ID: DbhDj2tTq64
--HG--
extra : rebase_source : c591787f31e6ba864178e27197cf6dff42e39a8d
We don't use the code to track the parents of each scroll id, so we can
dump it and just keep a set of scroll ids that we've defined to avoid
redefining them.
MozReview-Commit-ID: HY8y7xt9AJ6
--HG--
extra : rebase_source : 681154ae6494330f74c022243237b50d4921813b
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
