This was regressed by bug 1420512, which changed things so that
ScrollbarData::mDirection is set for both kinds of scrollbar layers.
MozReview-Commit-ID: 3UHFSOgDtWj
--HG--
extra : rebase_source : 25bc732e4216dbb1971bec57421e20698126f8f2
Same as the previous patch, but adapted for the sampler thread.
MozReview-Commit-ID: 7PVaPl38FkM
--HG--
extra : rebase_source : b7637270fea226cde15b9351a4ef8ac7ffab5796
This is possible if we just let the APZUpdater know during construction
if WR is enabled or not, and that information combined with the pref
will allow it to know whether to use the scene builder thread task queue
or just use the compositor thread as the updater thread.
MozReview-Commit-ID: 7IGMMtl7iFP
--HG--
extra : rebase_source : 3950adf77f4b48906b29cdb36f0437df1540bec6
We wrap the std::unordered_map in a StaticAutoPtr so that there's no
initialization cost, and also so that we have a smaller memory footprint
in processes that aren't using WebRender+APZ.
MozReview-Commit-ID: 9QCKiv0IzB8
--HG--
extra : rebase_source : 102d034478513f45da689bacffbc893370677ff7
This has a big performance impact because we instead of defaulting to the bounds
of the image we can use a much smaller temporary surface.
--HG--
extra : rebase_source : 0daba1adae742df3b983f80944dc4344bc70a5d6
Two AnimationValue are still used in AnimationPropertySegment since the
AnimationPropertySegment is used in compose_animation_segment() which is also
invoked on the main-thread, so we will fix it later in a bug that will drop
AnimationValue usage on the main-thread side.
MozReview-Commit-ID: B086g2qHtZL
--HG--
extra : rebase_source : 419308155bf95fb0acd94549c2c6cc9690925b29
This makes the APZ sampler thread be the render backend thread whenever
webrender is being used (not just when async scene building is enabled).
MozReview-Commit-ID: L9lmopd3pe7
--HG--
extra : rebase_source : a23793bf704a0bf3bc7ba6568ecfe5faa5720415
When sampling APZ transforms from rust code, we will need a timestamp at
which to sample the transforms. It's not obvious what the right
timestamp is to use here, and this will almost certainly be revisited
when we are hooking up OMTA in bug 1453360. For now we just stash the
most recent composite timestamp on the APZSampler and use that when
sampling. This seems to work fine.
MozReview-Commit-ID: KinsXO9tEJH
--HG--
extra : rebase_source : ffce8a9ac6720eea8583b03a613545ac5e9b48bf
The TransactionBuilder class comes with a bunch of baggage (it
automatically allocates/deallocates a transaction under the hood) which
we will want to avoid for the RB callbacks into APZ. This patch adds a
lightweight TransactionWrapper class that APZ can use to provide the
async transform info and that will be simpler to use in the callback
from rust code.
MozReview-Commit-ID: 1ywhx4TIzGd
--HG--
extra : rebase_source : 0ac4356554db24806d03b44f5384f9b7341d4255
Deferred tasks currently run as part of the sampling process, in
AdvanceAnimations. However, deferred tasks also sometimes need to acquire
the APZ tree lock for stuff. Acquiring the tree lock is not going to be
allowed on the render backend thread (which is the sampler thread when
WR is enabled), so we need to bump these tasks to another thread. The
controller thread is safe for this purpose.
MozReview-Commit-ID: AP3bnGF5UjL
--HG--
extra : rebase_source : 6fd81dfa488d1cada9941299e60a3d660a38895b
For webrender, we need to be able to sample the async transforms from nodes
and thumbs without holding the tree lock, since the sampling happens on
the render backend thread, and holding the tree lock would be a
threading violation. We can use the mApzcMap to sample the node
transforms, but for the thumbs we need to introduce another data
structure. This data structure packages up all the information from
the HitTestingTreeNodes that we need for the computation and stores it
protected by the map lock. This allows us to compute the transforms
safely while just holding the map lock.
MozReview-Commit-ID: BDMEbE78NnH
--HG--
extra : rebase_source : 754ceca695b5b3e1c87b1b2bde753d1775107e5f
This lets the APZSampler know which thread is the actual sampler thread.
This is only really used for the thread assertions, but might be useful
for debugging and such as well.
Note that since this behaviour is not dependent on any prefs (unlike the
updater thread, which is only the scene builder thread when the async
scene building pref is enabled), we don't hook it up to the rust code
just yet; that will happen in the last patch.
MozReview-Commit-ID: DrrJOyFA65D
--HG--
extra : rebase_source : 61e8e75ae16f95fe5ce95fa42a3dff501979ab9e
These prefs are on by default now, and so there's no point in keeping them as
override prefs.
MozReview-Commit-ID: Gzs65oS9koD
--HG--
extra : rebase_source : 89d52f7992a0e87f60673f3b7bd6efad627fd040
This is slightly efficient since we don't need to call
GetBaseAnimationStyle() or we do skip allocating animation data for such case.
MozReview-Commit-ID: BYFNwZsZ1oE
--HG--
extra : rebase_source : 441d7431bd444f1513a32d4da3c206c7df34ed94
This ensures we don't take the early-exit codepath introduced by the
PAINT_IDENTICAL_DISPLAY_LIST check, which breaks the behaviour desired
by forceLayerTreeToCompositor.
MozReview-Commit-ID: ECe6d0ZHZzt
--HG--
extra : rebase_source : 48d3f7d9b5df81ba165c0e52d1a7b78909c58774
This improves the DisplayList Mutate Talos test by about 5% on windows, as well as numerous smaller improvements on DisplayList heavy tasks.
MozReview-Commit-ID: tlEtPjqWI4
