Avoid sending a flood of WakeSceneBuilder messages when we get a series
of updater-thread tasks to run in quick succession.
MozReview-Commit-ID: 2irXrsahMPt
--HG--
extra : rebase_source : d5663824930792c7de03ef2eeaf2e638d2f57fa8
We need to allocate new AnimatedValue only if there is no AnimatedValue
corresponding to the id in the hashtable.
MozReview-Commit-ID: HeRt74Tnojt
--HG--
extra : rebase_source : 6920ac7fe770e928883e9995469e972799b3c02e
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
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 : 4554f908f42f761ddb2fca9be6bbe688c194c756
There's some cleanup happening in CompositorBridgeChild to release the
shared frame metrics when the client side is destroyed. However the code
is specific to PLayerTransaction, and is missing for the WR codepath.
This patch extracts the code to a helper and ensures that it runs for
the WR equivalent codepath.
MozReview-Commit-ID: ENJ349u0PTc
--HG--
extra : rebase_source : 0e6d728e603d077a371bbeedd3801ffcf11863cd
With WR+async scene building, the updater thread is no longer the
compositor thread, but we can only send the IPC messages from the
compositor thread. So we need to bounce those calls over to the right
thread.
MozReview-Commit-ID: 6M9bSLYLi5n
--HG--
extra : rebase_source : d908f22892f9d531266f100eeb4a863cb63d8270
mCanSend was being cleared in ActorDestroy which is fine, but we
actually cannot reliably send IPC messages from CompositorBridgeParent
after we get a RecvWillClose message, because that's the last thing that
the child side sends before it gets destroyed. After the WillClose
message there's no guarantee that the child side actor will still be
alive. So this patch also sets mCanSend to false in RecvWillClose.
mCanSend is only used in two places, both of which have to do with the
APZ metrics-sharing code, so this shouldn't have any unexpected
side-effects. It is needed for the next patch.
MozReview-Commit-ID: 8CuFienWVUU
--HG--
extra : rebase_source : 11e4455ffd8cd281d0a16ca34feb63fa89338ccc
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
