Although they still happen in the same transaction, they are done in two
separate frame messages. This results in better encapsulated code on the
C++ side since we don't have to pass around an array of properties, and
will simplify future changes to update these properties at render time
rather than at GenerateFrame time.
MozReview-Commit-ID: 9qUkHX7gmD1
--HG--
extra : rebase_source : 15a319ba270eb1783815c514ae05c6a72e323dac
With this commit, all the auto-dir scrolling functionalities are completed in
APZ.
MozReview-Commit-ID: L7qa3xOD8t9
--HG--
extra : rebase_source : bad2770219a0e6219f91899ab6c78e68f37195ac
This commit implements the auto-dir scrolling functionality in APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot
will be implemented in a future.
MozReview-Commit-ID: 9xai99x71gh
--HG--
extra : rebase_source : 118d188f730e3fb91d147b076a053cb04e622e55
Do some work in preparation for implementing actual functionalities for this
bug. No actual functionality change is involved in this commit.
MozReview-Commit-ID: 5aLhr38n1N4
--HG--
extra : rebase_source : 15cfc2cea5b7668367dd3bd4a0746ae8c61b7d20
Instead of passing a WrPipelineInfo* to C++ code, we can now pass the
WrPipelineInfo directly. C++ code can access the info members without
having to call back into rust code, so the wr_pipeline_info* iterator
methods can be removed. Deleting the structure still requires passing it
back to rust.
MozReview-Commit-ID: HYcPX3mCGKW
--HG--
extra : rebase_source : f4b781cfc463c8e196f67a6e178ce4ce44a9464a
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
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
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
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
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
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
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
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
This remotes the APZInputBridge interface over the PAPZInputBridge
protocol in the case of the GPU process, and makes the GPU process'
main thread act as the APZ controller thread in that process. If
there is no GPU process we continue as before and the APZInputBridge
interface implementation is the concrete APZCTreeManager instance
in the UI process.
The main changes in this patch are moving all the code associated with
these messages out of APZCTreeManager{Parent,Child} and into
APZInputBridge{Parent,Child}. APZCTreeManagerChild now returns an
APZInputBridgeChild instance via InputBridge(), instead of returning
itself. The SetControllerThread call in the GPU process is also updated.
MozReview-Commit-ID: M4AaIW1Q0h
--HG--
extra : rebase_source : e5a8f14e23be34229fe80a47f6789d19b19e0a9f
Sebastian Hengst
Kartikaya Gupta
Zhang Junzhi
Tristan Bourvon
Daniel Zielas
Andreea Pavel
Olli Pettay
Botond Ballo
Noemi Erli
Jan Henning
Xidorn Quan
Gurzau Raul
Ryan Hunt
Andi-Bogdan Postelnicu
jlogandavison
Emilio Cobos Álvarez
shindli
Boris Zbarsky