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
Doing paint flashing here doesn't work with the merging.
We'll need to do the flashing when we actually paint the blob.
MozReview-Commit-ID: KPujW43upQp
This appears to be unused, and is just needlessly calculating something.
MozReview-Commit-ID: Jpm9sBwJBfT
--HG--
extra : rebase_source : 0a743c6ed0f79b92715d2f902e9a607ccad0d1ea
It can happen often where we reuse the front buffer for a long paint, and then
the next frame we see that it is still locked, and need to allocate a new buffer
from the texture pool. If this happens we don't need to repaint the new buffer
because the old buffer is still around, but we do need to copy it over and
upload it to texture sources. It seems better to just hold onto the back buffer
and let it accumulate more invalid regions.
MozReview-Commit-ID: 2DQjwAX7ZmM
--HG--
extra : rebase_source : 3077952d3ef56deea6af68492f71bb114d96d84a
When we are creating a new back buffer we mark the whole region as being
invalid. This will cause us to paint extra in certain circumstances where
the visible region is a subset of the tile space.
MozReview-Commit-ID: BayRu0mV39O
--HG--
extra : rebase_source : b7eb40408faca5fc3fbc3e53263de7d262af35d5
Cosmin Sabou
Kartikaya Gupta
Jeff Muizelaar
Noemi Erli
Hiroyuki Ikezoe
Bogdan Tara
Andreea Pavel
Coroiu Cristina
Csoregi Natalia
Sebastian Hengst
Andrew Osmond
Miko Mynttinen
Bas Schouten
Jonathan Kew
Brindusan Cristian
shindli
Ryan Hunt