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
BLEND_MODE and BLEND_CONTAINER wrap items so their bounds can change.
We need to account for that like we do with OPACTIY etc.
--HG--
extra : rebase_source : fbd2d79eaad5c7347335416d369c8cae37aad447
ProtocolName() is only used for producing error messages and annotating
crash reports. But examining actual crash reports that would have used
the result of ProtocolName() indicates that we can always tell what the
erroring protocol is due to the stack backtrace. So having this virtual
function around just provides duplicate information, and it takes up too
much space in the vtable besides. Let's get rid of it.
The clipping code uses gfxContext::GetClipExtents which calls gfxContext::GetDeviceOffset
and DrawTarget::GetSize. The former was previously not being intialized, while the latter
was explicitly unimplemented. This patch fixes both of those facts.
Otherwise, enabling this functionality has been made trivial by several upstream patches
in webrender (the most recent being glenn's work on unifying shadows which eliminated
the buggy text-shadow shader code that was blocking this).
MozReview-Commit-ID: B1AlG3o4XQS
--HG--
extra : rebase_source : 2043c9c781f507c5d02041420145b1a5c59c0bb2
Currently in ContainerState::SetupScrollingMetadata we call
ComputeScrollMetadata for every layer and for each ASR in the layer's
clip chain. If there are many sibling layers with the same clip then
this is largely wasted work.
This change makes us cache the most recently calculated result, and
only recalculate if the ASR or clip is different.
There was a small portion of ComputeScrollMetadata that must actually
be executed for every layer and ASR in its clip chain. This has been moved
to a separate function, ClipLayerToDisplayPort, that is still called
every time.
MozReview-Commit-ID: 7Zzblmimtc5
--HG--
extra : rebase_source : d39908b2be2565d22079b3e5e8df56316159a918
Note that we have to calculate animation values if there is another animation
since the other animation might be 'accumulate' or 'add', or might have a
missing keyframe (i.e. the calculated animation values will be used in the
missing keyframe).
MozReview-Commit-ID: rQyS9nuVJi
--HG--
extra : rebase_source : 6ddc70308e223a709eba9c4c2f05e42bbc0f3160
In the next patch, we skip updating animation value for the layer if the
animation value isn't changed. So without this patch, we will have to update
animation value even if the value isn't changed at all.
MozReview-Commit-ID: 9tU7BTkNOHL
--HG--
extra : rebase_source : 0dbaaab9e52108c843f2d378785a67a8f374994c
We don't need to calculate TimingParams each time we compose an animation on
the compositor because TimingParams is immobile since the animation was sent to
the compositor.
MozReview-Commit-ID: 3rfzkdGClES
--HG--
extra : rebase_source : e28650a30b1cbd14789688f2acc03d204069e2fb
On the testing refresh mode, we shouldn't update mPreviousFrameTimeStamp and
don't need to use it since there shouldn't have any time difference between
compositor time stamp and main-thread time stamp on the testing mode.
MozReview-Commit-ID: FCcyEcFhmU
--HG--
extra : rebase_source : 027c8019fbe8a43a8ef6b454204e329a483ab4f5
These tasks have an implicit ordering with other tasks that are
dispatched from the compositor thread to the updater thread, and so they
need to be bounced through the updater thread before we run them on the
controller thread.
MozReview-Commit-ID: 92nIYgyV8A2
--HG--
extra : rebase_source : c5edc5cb50dd44d1979d805bf17e707e1c8abac1
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
