In MultiTiledContentClient we can create a DrawTargetTiled with a
different origin than the layer we are painting. We must therefore
ensure when edge-padding that we provide the valid region in the draw
target's device-space rather than layer-space. Not doing so was
causing us to pad out in incorrect directions, causing visible seams.
Differential Revision: https://phabricator.services.mozilla.com/D3993
--HG--
extra : moz-landing-system : lando
This commit exposes a method on DrawTargetCapture to see if it has
captured any drawing commands. This allows us to not dispatch
paint tasks if they will do nothing.
Ideally these tasks would execute instantly on the PaintThread, and
we would never delay sending the layer transaction or block on the
next paint, but with thread starvation and context switches it's
best to just not send them.
MozReview-Commit-ID: 7ywkEDBw6EX
--HG--
extra : rebase_source : c60c1c25d551e4a7c14c529137f8e0babc888466
extra : source : 7ae4c893867a5f7df81e0757d4b4a6a21cbc6986
This commit adds the ability to create a different kind of DrawTargetCapture which
has a limit on the size of which its CaptureCommandList can grow before it is
synchronously flushed to its destination DrawTarget.
Special care is taken to not do a sync flush until we would need to resize
the backing store of the CaptureCommandList. This allows us to not waste
memory we've already allocated.
The async painting content clients are updated to use it, and get a default
value from a new preference.
MozReview-Commit-ID: CJL7ffvaRzR
--HG--
extra : rebase_source : f646862dcef7a480b21dfb7ddb1fa165338ba506
extra : source : b865a866fe5a3257615cb54b7e5e790cc9331988
This commit adds a buffer unrotate operation to DrawTarget. It's
initially implemented with LockBits in DrawTarget. DrawTargetDual
overrides the implementation to pass on the operation to it's
DrawTargets.
No override is given for DrawTargetCapture as we intentionally
avoid this code path when async painting as it can fail.
This is needed so that RotatedBuffer can expose a single DrawTarget,
which can be a DrawTarget (for normal alpha), DrawTargetDual (for
component alpha), or DrawTargetCapture (when async painting).
MozReview-Commit-ID: csjjZ733hl
--HG--
rename : gfx/layers/BufferUnrotate.cpp => gfx/2d/BufferUnrotate.cpp
rename : gfx/layers/BufferUnrotate.h => gfx/2d/BufferUnrotate.h
extra : rebase_source : 5d96e2a5d36a01f2f9992adb37830e56436c7c35
extra : source : 64cb50b227e0ae604653f03ce2e892493126392e
This commit adds the ability to create a SourceSurfaceDual directly,
instead of only from a DrawTargetDual. This allows SourceRotatedBuffer
to expose itself as a single SourceSurface for a later commit.
MozReview-Commit-ID: K21K42cGDy1
--HG--
extra : rebase_source : d3fe48ac711f9cd28799bfd8d36b74750cb15554
extra : source : 392a724d5acd25854e871fa47335c4b938fe9ae1
This commit adds an operation to perform 'edge padding' on a draw
target. By default this is performed using LockBits, but it's
overriden in DrawTargetTiled and DrawTargetCapture to propagate
the call so it functions correctly.
This helps TiledContentClient move from applying this operation
on a per texture client basis, to being able to do it on the
DrawTargetTiled after painting. This in turn helps move all
paint thread operations into DrawTargetCapture.
MozReview-Commit-ID: 2ncOTxGXQfk
--HG--
rename : gfx/layers/BufferEdgePad.cpp => gfx/2d/BufferEdgePad.cpp
rename : gfx/layers/BufferEdgePad.h => gfx/2d/BufferEdgePad.h
extra : rebase_source : a3315644fe31f2a432935dcbfdb9969c58b691e1
extra : source : 699c954992f87db7fc792f5562090de42a8162cb
This adds a DrawTargetOffset which is basically a simplified
DrawTargetTiled that only supports one tile. It useful for situations
where Cairo's device offset was used previously.
This also replaces WebRender's use of DrawTargetTiled which was just trying to
apply offset.
MozReview-Commit-ID: I33PB6CnHh0
--HG--
extra : rebase_source : 9fa51a0180343231cfca41daa0e3fa53f1b7befe
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
We can easily use Maybe<DataSourceSurface::ScopedMap> instead of
allocated the map on the heap. This does require some minor changes to
ScopedMap to properly support moves, but should be much more efficient.
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
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
Currently, we use a simple merging algorithm, because the more
complicated ones didn't work.
This code won't actually be used until we do blob image invalidation
in a follow up.
MozReview-Commit-ID: Q2Em3QC195
The shared memory handle reporting has been generalized to be an
external handle reporting. This is used for both shared memory, and for
volatile memory (on Android.) This will allow us to have a better sense
of just how many handles are being used by images on Android.
Additionally we were not properly reporting forced heap allocated
memory, if we were putting animated frames on the heap. This is because
we used SourceSurfaceAlignedRawData without implementing
AddSizeOfExcludingThis.
This makes it possible to implement nsDisplayBlend blob image invalidation.
It currently only includes an implementation for Skia and DrawTargetRecording.
All other backends will crash when used.
MozReview-Commit-ID: 2GhdDxi4jHG
Add a command CreateClippedDrawTarget to DrawTarget, which takes the
max required size and a transform between this draw target and the one
to be created. The created draw target may have its size clipped to
the size of this draw target, transformed to the new target's
space. This means that the new surface will be large enough so
that it is rendered to this draw target correctly, but not necessarily
any larger.
Usually this will just create a draw target of the requested size, for
simplicity. However, when replaying a recorded draw target we do clip
the size to the base draw target's size. This is done using a
DrawTargetTiled, so when applying the mask in PopLayer, we must take
the SourceSurface's offset in to account.
MozReview-Commit-ID: 89ONElphzLu
--HG--
extra : rebase_source : 7eebeb66a2686a7b6f4ade36f3004ebb06abc2fe
Fix the DrawTargetTiled::mRect initialization, and expose through the
virtual function GetRect(). Make SnapshotTiled::GetDataSurface()
allocate a surface the size of this rect, rather the XMost and
YMost. Callers of SourceSurface::GetDataSurface() can query
SourceSurface::GetRect() and apply the necessary offset themselves.
MozReview-Commit-ID: C31FGirQ0oK
--HG--
extra : rebase_source : ac31ae3ca0a0b188f9293c4e6898b4e4a65cad0e
This patch takes the safest route for securing modifications to the dependency graph for D2D DrawTargets. It's possible a slightly optimal approach is possible, however lock contention should be rare and I believe this is the safest and most upliftable approach.
MozReview-Commit-ID: HGfSdEp2U5N
This patch takes the safest route for securing modifications to the dependency graph for D2D DrawTargets. It's possible a slightly optimal approach is possible, however lock contention should be rare and I believe this is the safest and most upliftable approach.
MozReview-Commit-ID: HGfSdEp2U5N
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
Patch originally developed in bug 1406138, but landed in bug 1405790 since it
needs to land together with the upstream WR changes in PR 1816.
MozReview-Commit-ID: IHVoKhVncd5
--HG--
extra : rebase_source : 912e3d903d71c1b664817457e67aa6d81be3f4dd
This keeps around mFinalDT but mostly doesn't use it (except for when creating
a PathBuilder). All playback is ripped out and we'll no longer hold references
to things to mFinalDT::GraidentStops or SourceSurfaces etc.
This helps keep us from accumulating all of the recorders.
The basic idea is to track weak references to the SourceSurfaces and Fonts that
we add UserData to in DrawEventRecorderPrivate and then clear these UserData's
when we're done recording.
This adds a RemoveAndDestroy helper to UserData to make this possible.
We need to grab UnscaledFont objects through WeakPtrs during metrics
calculations, but this only happens on Servo style worker threads
while the Servo font metrics mutex is locked (and while the main
thread is paused). So we use WeakPtrTraits to override the
thread safety assertion to allow OMT access through the WeakPtr
if the mutex is locked.
Since we can end up creating UnscaledFont objects from the style
worker threads too, we additionally need to allow the main thread
to access them through WeakPtrs.
It would be nice to avoid the dependency on layout/style/ here, but
I can't see a way to do that without putting the burden of the
annotation that the more permissive thread safety checks are allowed
on the WeakPtr<> declarations themselves.
MozReview-Commit-ID: AbHNZEhE7L8
--HG--
extra : rebase_source : 48fba82778c1015a764a3cd921475966b67bf70a
We need to grab UnscaledFont objects through WeakPtrs during metrics
calculations, but this only happens on Servo style worker threads
while the Servo font metrics mutex is locked (and while the main
thread is paused). So we use WeakPtrTraits to override the
thread safety assertion to allow OMT access through the WeakPtr
if the mutex is locked.
Since we can end up creating UnscaledFont objects from the style
worker threads too, we additionally need to allow the main thread
to access them through WeakPtrs.
It would be nice to avoid the dependency on layout/style/ here, but
I can't see a way to do that without putting the burden of the
annotation that the more permissive thread safety checks are allowed
on the WeakPtr<> declarations themselves.
MozReview-Commit-ID: AbHNZEhE7L8
--HG--
extra : rebase_source : 95e669d64a0881ef1c9747c2e7de7f361865af11
(These are adding headers for types that are used in the modified files, to
provide those types' definitions.)
MozReview-Commit-ID: 1OeUH0LHztw
--HG--
extra : rebase_source : 8db5cfa60b79df31eb885cdd3f2ccffc8387ee08
Bas Schouten
Lee Salzman
Jamie Nicol
Ryan Hunt
Jeff Muizelaar
Andi-Bogdan Postelnicu
Andrew Osmond
Emilio Cobos Álvarez
Cosmin Sabou
Sebastian Hengst
Tristan Bourvon
Masatoshi Kimura
Margareta Eliza Balazs
Chris Peterson
Markus Stange
David Anderson
Daniel Holbert
Nicolas Silva
Mason Chang
Carsten "Tomcat" Book
Kevin Chen
Cameron McCormack
Iris Hsiao
cku
Jeff Gilbert
Kartikaya Gupta
Wes Kocher