The GTests don't have a way of setting up the relevant state in WebRender
for the hit test to succeed.
MozReview-Commit-ID: IyjK349MN5u
--HG--
extra : rebase_source : 9bc662601b6424fc956107a04f03e7d979bb1d1c
Part of this is a backout of bug 1421054 which is no longer needed now
that we can assume equivalent clip items have identical pointer values.
MozReview-Commit-ID: BhnLVmVr4TX
--HG--
extra : rebase_source : b9bbb733fc69a0f15cd35d0265589aea257a5285
See the documentation in the added function for details.
MozReview-Commit-ID: 4R0WaSy0tm2
--HG--
extra : rebase_source : f6bcdafb708f9527afafab54e3ba7e34040054b0
When a clip is defined in WebRender, any transforms on the containing
stacking contexts are baked into the clip's position. Therefore, trying
to use a clip that was defined inside a transformed stacking context in
other parts of the WR display list doesn't work properly. This was a
latent bug in ScrollingLayersHelper that was previously not exposed
because in these cases Gecko itself creates separate
DisplayItemClipChain items. Now that we are going to deduplicate those
DisplayItemClipChain items, it exposes this latent bug which we need to
fix.
MozReview-Commit-ID: Icd7L1JuY8s
--HG--
extra : rebase_source : 08749125b68b537244a054d00a41f671670d00bb
Mechanism for restricting pinch zooming when gesture is a two
finger pan. If the pinch span is below a given threshold and the
scroll distance above a given threshold then the zoom level is
maintained to allow for smooth panning with two fingers.
MozReview-Commit-ID: 62Fv0WeplOo
--HG--
extra : rebase_source : 71d7da4c4b4cc3a5adde13ad1a7c1fbf49856c35
SourceSurfaceSharedData objects have a WrImageKey associated with each
WebRenderBridgeChild/WebRenderLayerManager pairing. Normally this key is
only regenerated when the surface itself needs to invalidate. However
when a tab is moved (e.g. dragged into a new/different window), the
WebRenderBridgeChild's state will be reset. Any existing keys were
discarded and it has a new namespace. SourceSurfaceSharedData needs to
take this into account, and generate a new key when there is a namespace
mismatch.
This commit adds a paint worker thread pool to PaintThread, and dispatches
tiled paints to it. The thread pool is only created if tiling is enabled,
and its size is set by 'layers.omtp.paint-workers' and defaults to 1. If
-1 is specified, it will be sized to 'max((cpu_cores * 3) / 4, 1)'.
The one tricky part of dispatching tiled paints to a thread pool is the
AsyncEndLayerTransaction message that must execute once all paints are
finished. Previously, this runnable would be queued after all the paints
had been queued, ensuring it would be run after they had all completed.
With a thread pool, there is no guarantee. Instead this commit, uses
a flag on CompositorBridgeChild to signify whether all of the paints
have been queued ('mOutstandingAsyncEndLayerTransaction'), and after
every tiled paint it is examined to see if that paint was the last
paint, and if it is to run AsyncEndLayerTransaction. In addition,
if the async paints complete before we even mark the end of the
layer transaction, we queue it like normal.
The profiler markers are also complicated by using a thread pool.
I don't know of a great way to keep them working as they are per
thread, so for now I've removed them. I may have been the only
one using them anyway.
MozReview-Commit-ID: 5LIJ9GWSfCn
--HG--
extra : rebase_source : 0c26806f337a1b4b1511945f9c72e787b426c5ba
This makes it so that each tile of a paint gets a DrawTargetCapture and
its own buffer operations. Once this is done, each CaptureTiledPaintState
will be isolated from each other and able to be done in parallel.
MozReview-Commit-ID: BuBDXgjma4z
--HG--
extra : rebase_source : 6ae3dc439ebc19bcaada9486894d542d138a460d
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
Additionally, various C++ code and style cleanup
MozReview-Commit-ID: 7BCtQzFGaOc
--HG--
extra : rebase_source : 77598165c0f6ad9f04c8a09985c79df82f2732e4
Currently ContentClient will attempt to create a buffer of any size
that Layers requires it to. If that fails it will then warn if the
requested buffer was an unreasonable size. This change makes it so
that we check whether the size is reasonable first, and do not attempt
to create the buffer if it is unreasonable.
Previously the operating system would have managed to allocate some
buffers that we deem unreasonable, but at the cost of the system
becoming unresponsive. Now, some large buffers which would previously
have been created won't be, but the chances of the system becoming
unresponsive should decrease.
Ideally Layers wouldn't request buffers of these sizes in the first
place - there are measures in place to try to prevent it, and more work
is certainly required. However, this will act as a last ditch defence.
MozReview-Commit-ID: 7WCqEwkmViy
Chris Peterson
Csoregi Natalia
Nicolas Silva
Noemi Erli
Milan Sreckovic
vincentliu
Botond Ballo
Dorel Luca
Ryan VanderMeulen
Morris Tseng
Kartikaya Gupta
Jeff Gilbert
jlogandavison
Ryan Hunt
Andrew Osmond
Andreea Pavel
Alexis Beingessner
sotaro
Andrew McCreight
Jean-Yves Avenard
Jamie Nicol
Daosheng Mu
Gurzau Raul