This changes the code around mFollowing group size changes to match
the code in DoGroupingForDisplayList. Specifically, it makes sure
we always ClearItems() on size changes even if we don't have a key.
--HG--
extra : rebase_source : 2063974082862906a2831bdd76ac86871ee3dbc3
This allows us to treat tasks from different layers id as independent,
thereby removing the unnecessary latency increase as described in bug
1449982 comment 33.
Note that we could probably implement this by actually maintaining
separate queues for each layers id, but that involves more overhead
since we would need to have a map from layers id to task queue, and
removing entries from that map becomes tricky with respect to locking
and timing.
MozReview-Commit-ID: 7jtYqNDwJqP
--HG--
extra : rebase_source : d55fa2c20c5e78a330033dcf049d5cc468024bb0
This makes it so that we only process a UpdateHitTestingTree task (and any
tasks queued after it) once we know that the corresponding scene has
been built and swapped in by WebRender. This ensures that processing of
APZ data stays in sync with the active scene in WR.
The way we do this is by tracking the "epoch" (which is updated per
WR/layers transaction) that the APZ messages are based on. Only once the
scene for that transaction is swapped in do we process those messages.
MozReview-Commit-ID: 2qGTSTeSqve
--HG--
extra : rebase_source : fb4cb0df3970213d01e21a792957ad22771a0637
This allows us to easily store a handle to the APZUpdater on the
WebRenderScrollDataWrapper class and walk around in the scroll data tree
without having to query other classes like CompositorBridgeParent or
WebRenderBridgeParent when we encounter a reflayer boundary.
MozReview-Commit-ID: 6l7oMb7tBlW
--HG--
extra : rebase_source : d21b64317eaf40f743fb7354b3292ab0f54a6d05
I don't know why we keep using plain uint32_t and uint64_t values when
we have better types that we can use. This makes the code use and store
wr::Epoch natively instead of raw uint32_t values that are wrapped
on-demand.
MozReview-Commit-ID: HUVcHYSxBTi
--HG--
extra : rebase_source : 9e8f367f864483a65273cbbeb1168587841279f0
If we're using the WR scene builder thread as the updater thread, we
cannot just post a task to its message loop, because it's a rust thread
that doesn't have a message loop. Instead, we put these tasks into a queue
that we will process in callbacks that are invoked from the updater
thread.
This patch just adds the basic queue machinery, it will get more
complicated in a future patch because we need to gate the tasks to make
sure they don't run too early.
MozReview-Commit-ID: 8DCYbsQ5cBC
--HG--
extra : rebase_source : 7081fb187436451b0c9d654f2e31c486d25924d7
This lets the APZUpdater know which thread is the actual updater thread.
This is only really used for the thread assertions, but might be useful
for debugging and such as well.
MozReview-Commit-ID: IIDm6Ui3Sh4
--HG--
extra : rebase_source : 575ba6c0c5d56276743e81e738e73e7672e08367
This is all the (bidirectional) glue that connects the SceneBuilderHooks
to the APZUpdater.
MozReview-Commit-ID: JIqUaClVa57
--HG--
extra : rebase_source : c6da81e63793570f79cdfa153f6d33d2ac05bdf6
Until all the pieces are in place, turning on this pref will probably
break horribly. But we need the pref so we can add the rest of the
pieces without enabling them by default.
MozReview-Commit-ID: 7DkcwZgXwhx
--HG--
extra : rebase_source : e1fdef2e9a682028df524f51f767a4d2187410b1
This will allow callbacks from rust code to get a handle to the
necessary APZUpdater instance on which to invoke functions.
MozReview-Commit-ID: 13XdzZrrtI5
--HG--
extra : rebase_source : 137af2a4c738a6e9294972be9e0566c9fdef58ac
This includes a signature change from CompositorBridgeParentBase ->
CompositorBridgeParent which is not strictly required, but it makes it less
likely that we'll accidentally create a WebRenderAPI from somewhere else
and pass a nonsense window id. In effect, the signature change makes it
likely that only CompositorBridgeParent will allocate the window ids.
MozReview-Commit-ID: 8AnnmI8RytR
--HG--
extra : rebase_source : 6fd957c4a9e5bb2175bee2cc89f7eb6d27a6bc9e
This updates existing bits of code (notably one of the GetTargetAPZC
methods) to use the new map for more efficient lookups. Places that
used GetTargetNode with a presshell-ignoring comparator can now use
GetTargetAPZC as well.
MozReview-Commit-ID: GFjO6KigVop
--HG--
extra : rebase_source : 336a7118927bd6c3f0e4edaf15770afb1f6602a9
We are already building an almost-what-we-want map in the
TreeBuildingState, so I modified to be exactly what we want, and then
just move it to the APZCTreeManager once the tree build is done.
MozReview-Commit-ID: 40RVwYv93wR
--HG--
extra : rebase_source : 118b28dfb796f8153d07dfb356eb45a0d8298c8d
This is mostly just moving the existing hash function and introducing
additional helpers to create maps with presshell-ignoring guid keys. We
can use this in one place trivially so I did that as well.
MozReview-Commit-ID: G8nMS1PECT4
--HG--
extra : rebase_source : 4f34da9db77f7ec4b7e5ebaeccd532c8f8c92283
If we have a non-null mTarget, we already set mDrawTarget to mTarget. So "mTarget ? mTarget : mDrawTarget" will always evaluate to mDrawTarget.
MozReview-Commit-ID: BlGYEdlL50Q
--HG--
extra : rebase_source : 214baea43d160c85d06cc11931c1c10d9a6ae4d2
The same condition is checked just before this if, so it's always true.
MozReview-Commit-ID: 9Vscnkz7AoY
--HG--
extra : rebase_source : d4209c6eb3963762c76a7dc4e1344147ae63f71a
This was incorrectly using the invalid rect, so it was clearing more than
necessary and not taking advantage of the opaque region that the caller computes.
The idea is that we don't need to clear parts of the invalid region that will be
covered by something opaque.
MozReview-Commit-ID: LhEkVUMnjC9
--HG--
extra : rebase_source : 97e0124684fbe6f3231795abf0591d25db0768db
It's not needed, because by default std::unorderd_map will use
std::equal_to which delegates to the operator== on LayersId which does
the same thing. We don't need to reimplement it.
MozReview-Commit-ID: CLJO2JJfbF4
--HG--
extra : rebase_source : c8f5c254f00ab5e96c5d6e140534465c5a52c5af
Original patch by Ethan Lin <ethlin@mozilla.com>.
MozReview-Commit-ID: AAIaskIsz9x
--HG--
extra : rebase_source : 879144b98467f47867d66f2806d7d31dbcf2bc7b
A component of dtSize could be zero because RoundedToInt(rect).Size() is not the same as
RoundedToInt(rect.Size()). The size after rounding might be zero, even if the rounded size
is not zero. For example with x0=0.5, x1=1.1.
MozReview-Commit-ID: 3NeBMAVD5ub
--HG--
extra : rebase_source : a241b10aa6e1e788691cfb7ac412fe5073257c81
extra : amend_source : 8d55d933c021b77463eb6c4fe0a2503fc9bf78d7
If we don't do that, in the case of a root scrollbar the clip transform passed
to our caller will incorrectly be scaled with the current content resolution.
This means that that the position of the clip rect won't match the actual
position of the scrollbar if the resolution isn't ~1.0, so the scrollbars will
be clipped out of existence when the content is (pinch-) zoomed in or out.
MozReview-Commit-ID: 5yXa9EpTJ2g
--HG--
extra : rebase_source : 88c3b5a8613a3d6ef0c753116ebf9efe9ffc0022
Now that WebRenderUserData's a keyed on T::Type() we don't need to check it
after doing the lookup.
--HG--
extra : rebase_source : e20db22489b7689a241a79d2d74a54a220a60e3f
LayerManagerMLGPU does not have a compositor so this line will force the TextureHost to
reupload the buffer later in this function when the TextureSource is set correctly.
--HG--
extra : amend_source : 57f41549565cf770c98ace6d49460d21468568a7
This reworks bug 1440561 so that we only precompute loads that belong to our
user font set, avoiding messing up with fonts in the cache that belong to other
pages.
The loadability of a font is precomputed in PreTraverse in the same way as we
did, but only for the fonts that we may end up loading. This is stored in
FontFaceSet now.
Also, the principal shenanigans that this code did are reworked to be explicit
about when the document principal changes in ResetToURI, instead of having a
member around and a mutable variable. This makes the code easier to follow.
MozReview-Commit-ID: 9ofTbaLDUF7
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
The APZUpdater class holds the methods that are to be run on the updater
thread. Note that there are a few differences between the APZSampler and
APZUpdater classes - most notably, APZSampler no longer has a
"RunOnSamplerThread" function because there should never be any need to
dispatch runnables to the sampler thread. There is still a
RunOnUpdaterThread in APZUpdater, as well as a mechanism for dispatching
runnables to the controller thread via the updater thread.
MozReview-Commit-ID: LLVWzRyhYWl
--HG--
extra : rebase_source : d3d2ae18b40f24473cab5567a48b67b8f478a733
Functions in APZSampler that are only invoked without WR (e.g. from
AsyncCompositionManager only) can be asserted as running on the sampler
thread. Functions that are invoked with WR need to be bounced onto the
sampler thread. In all cases the functions are called from the
compositor thread, and so we assert that as well.
MozReview-Commit-ID: JPgGlgUUsgg
--HG--
extra : rebase_source : 8b950d3386e1e64e766b76edaa7894b251fb8664
The methods on PAPZCTreeManagerParent are always invoked on the
compositor thread, which currently is always the same as the sampler
thread. When it does RunOnControllerThread calls, there is an implicit
ordering with respect to the sampler thread, because the controller
thread messages are always dispatched *from* the sampler thread.
When we move the sampler thread to be the render backend thread, we have
to preseve this implicit ordering, but we have to make it more explicit.
For example, if a content process sends a layers update followed by
a SetTargetAPZC message, it expects that the APZ will process them in
that order, as the SetTargetAPZC might refer to a scrollframe that was
just layerized. Currently, both these messages arrive on the compositor
thread; the layers update is processed directly as the compositor thread
is the sampler thread, and then the SetTargetAPZC message is bounced to
the controller thread. However, if the compositor thread is not the
sampler thread, then we would bounce the layers update to the sampler
thread, and bounce the SetTargetAPZC to the controller thread,
introducing a race. If SetTargetAPZC runs first bad things happen. The
solution in this patch is to bounce the SetTargetAPZC to the sampler
thread as well, so that it gets bounced to the controller thread only
after we have processed the layers update.
This patch accomplishes that by introducing a method on APZSampler that
does this "double bounce".
MozReview-Commit-ID: KI9wQQ9PZT4
--HG--
extra : rebase_source : 79d0d36a649f11cc795148cc86539a526c8beeae
This is functionally a no-op (it just moves the thread-bouncing code
from inside APZCTreeManager::SetLongTapEnabled to the call site in
APZCTreeManagerParent. The other call site, in
widget/android/nsWindow.cpp, is already known to be running on the
controller thread (which would be the Java UI thread in that case).
This makes the code in APZCTreeManagerParent more consistent and
simplifies the next changes.
MozReview-Commit-ID: 8VfEDVVFNl8
--HG--
extra : rebase_source : 02225ed5b80129a1d18b429eff93866a33d4ea86
Note that this also makes the utility functions instance methods,
because each APZSampler might have a different sampler thread instance.
MozReview-Commit-ID: 9dY8ZzVX6lR
--HG--
extra : rebase_source : 4dd58400aee5d9f2063abe0a912488b28ff74f9f
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
Due to an oversight in bug 1423370, the code I added was setting the
transform on a WebRenderLayerScrollData after initializing it, but the
initialization might have populated the transform. Thus the
transform-set that I added would have clobbered the transform. This
updates the code to combine the two transforms instead which avoids
the clobber.
MozReview-Commit-ID: 4mKJTLSMD9J
--HG--
extra : rebase_source : c486c5866739ab040d81f9f9a43b2b8a04c2d383
Instead of creating a new layer scroll data for every single
nsDisplayTransform item, we only create a new layer scroll data for
nsDisplayTransform items with perspective. In addition, we save the
transform from the non-perspective nsDisplayTransform items on the
StackingContextHelper, and then apply it to layer scroll data items that
are created by display items nested inside those nsDisplayTransforms.
This effectively makes two changes to the structure of the layer scroll
data sent to APZ:
(1) we will drop layer scroll data items for transforms that APZ doesn't
care about (i.e. the non-perspective ones that don't wrap APZ-relevant
display items).
(2) we will collapse layer scroll data items that only had a transform
into its descendant layer scroll data items. This should be functionally
equivalent, since the transform is still in the right place relative to
everything else.
The net result is fewer layer scroll data items.
MozReview-Commit-ID: HV6QPfuUrje
--HG--
extra : rebase_source : ecfe1810f9889e7ce5096e1bc42cc30a92b43b4a
Apparently applying it on an individual function inside the extern "C"
block doesn't work so we have to apply it to the whole block. But that's
better than applying it to the whole crate.
MozReview-Commit-ID: GUMliaZragl
--HG--
extra : rebase_source : d12ac26aea76bc7c4487e80e6066a016871d1d20
Instead of hard-cording the root scroll frame id, get the value from
WebRender. This was previously hard-coded to 0, so when WebRender
switched to using 1 for the root scroll frame id, the positioning of
sticky frames were broken in subtle ways. This happened because they
were being parented to a root reference frame (which now uses the 0 id)
instead of the root scroll frame.
MozReview-Commit-ID: 66ArgKHGpWE
--HG--
extra : rebase_source : ff6937bf7fc8d4472eb074d0466c8dcd6fba54a8
Summary:
I can propagate the error up if needed, but looks like the code should cope with
it just fine with this change.
Reviewers: kats
Bug #: 1446108
Differential Revision: https://phabricator.services.mozilla.com/D794
MozReview-Commit-ID: Dm6EKIC6F5i
