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 moves ContentClient from creating a CapturedBufferState for
buffer operations, to performing all of those operations on the
DrawTarget(Capture). Creating a DrawTargetCapture is now performed
by the RotatedBuffer when we BeginPaint, all operations are performed
on this capture, and then it's returned to the ClientPaintedLayer
as a PaintTask.
This commit is an involved refactoring of ContentClient and RotatedBuffer
to get this all to work. Here are the major parts:
1. RotatedBuffer is refactored to always perform operations on a single
DrawTarget, which may be a single DT, dual DT, or capture.
2. RotatedBuffer adds BeginCapture and EndCapture methods to switch
which DT is used in operations
3. ContentClient uses the RB capture methods when we are async painting
4. CC::BeginPaint is refactored to only perform capturing on a single
RotatedBuffer. This is because we can't have the output of one
PaintTask be the input of a different PaintTask due to the design
of the Snapshot API.
a. This can occur, today, by doing a FinalizeFrame only to later
fail to Unrotate the buffer, causing a new RB to be created
and painted into
b. The previous PaintThread code worked because it used the
buffer operations which didn't use Snapshot's
c. This is fixed by not doing FinalizeFrame on a buffer if we
realize we cannot unrotate it, and switching to initializing
a buffer using the front buffer which should be up to date.
d. I don't like touching this code, but it passes reftests,
might be a performance improvement, and I've tested it on
known regressions from the last time I messed up this code.
5. CC::PrepareForPaint is inlined into BeginPaint because dual draw
targets can be cleared correctly from a previous commit
6. The code paths in ClientPaintedLayer are unified because we no
longer need to special case this beyond setting the correct
ContentClient flag.
7. CapturedPaintState and CapturedBufferState are removed in favor
of PaintTask. Additionally EndLayer is no longer needed as all
quadrants of a rotated buffer are in the same capture, so we
don't need special case flushing code.
MozReview-Commit-ID: 9UI40dwran
--HG--
extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b
extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
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 renames CapturedTiledPaintState to PaintTask as in a future
commit I will fold CapturedPaintState into it.
MozReview-Commit-ID: 8py7SrK4s29
--HG--
extra : rebase_source : 7abdf127351cdc82ee4c40112dce7150bdb67243
extra : source : 01110727f2e9e0846fc06997653e04860efb23dc
This commit refactors TiledContentClient to not create PaintThread
buffer operations, but to instead perform all of these operations
on the DrawTarget(Capture). This simplifies the code dramatically
and allows us to add flushing behavior to DrawTargetCapture in a
future commit.
With this change, CapturedTiledPaintState is simply a container
for a DrawTarget, DrawTargetCapture, and keep-alive TextureClients.
Part of this commit is moving the logic of locking the texture
clients, constructing a dual draw target, and constructing a capture
into TiledContentClient so it can be shared.
MozReview-Commit-ID: 2rwz9aDI737
--HG--
extra : rebase_source : 4ac317f632c0a2c21480bc88e6246f4dc0daf0be
extra : source : 56d967e03ee225e032034ffd193b6f42b343226b
This commit adds a RAII class for the common operation of attempting
to lock one or two TextureClients and then maybe constructing a
DrawTargetDual from them.
MozReview-Commit-ID: ECQkDSgpyuL
--HG--
extra : rebase_source : 6debecb9d4ca33895daa78de3a52a1ed575706e1
extra : source : 082638a5c6432e0ca6ce377986d84ed130b32ad3
This commit changes the behavior of DrawTargetDual::Clear to be aware that
it has on-white and on-black buffers, and perform clearing appropriately.
This is slightly against what the DrawTarget documentation says the method
should do, but it allows us to move another paint thread operation into
DrawTargetCapture and simplify our ContentClient implementations.
I haven't seen any obvious breakage with this, and reftests are green.
An alternative would be to add a separate Clear method with documented
difference here.
MozReview-Commit-ID: 65CzcxlRqv7
--HG--
extra : rebase_source : 299adbb02e79f66f7d6860c5fe86784bad8332f8
extra : source : 3dc47f17fa446bb7f2b5876753f8271a93c0e0c8
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
We already copy the 64-bits libraries, but don't copy the 32-bits
libraries, which prevents building for linux32 by default.
Incidentally, this also makes the clang build system build the 32-bits
compiler-rt libraries, allowing e.g. 32-bits PGO.
We only enable libstdc++ compat on Android for the host parts, and
in practice, the target part has it not enabled at the moment because
libstdc++ can't be found. But making the clang toolchain capable of
building for x86 changes the deal for Android x86.
system-info is a stub on Tier3 platforms while physical vs. logical
difference only matters for hyper-threading. As hyper-threading
is usually available on CPUs with more than 2 physical cores this
change has no impact there as the default is clamped to [1, 4].
However, on Intel i3-* CPUs with 2 physical and 4 logical cores this
bumps the default from 1 to 3.
MozReview-Commit-ID: 1Yh8rJL2JcN
--HG--
extra : rebase_source : 5c563ec8e388a3fd05a0650e8d4c330d48675332
Summary:
This disables building avx512 due to difficulty in getting a working set of
compiler flags across our supported platforms. Rather than carrying this patch
forward, we should revisit supporting avx512 when we do the next update.
Reviewers: jya
Tags: #secure-revision
Bug #: 1433158
Differential Revision: https://phabricator.services.mozilla.com/D2942
--HG--
extra : rebase_source : 0b828be5559a985a8ec5f12d6712b970545d0d83
Summary:
This patch is already applied to the webrtc.org code and doing a libvpx update
does not remove it, so having this present leads to merge conflicts during the
update as it attempts to patch already patched code.
Reviewers: jya
Tags: #secure-revision
Bug #: 1433158
Differential Revision: https://phabricator.services.mozilla.com/D2939
--HG--
extra : rebase_source : e641e8645467565f329c72f0869fe18aa2def846
When iterating on taskgraph changes, the exact number of chunks that
test-verify runs usually isn't important, so skip it when going fast.
Differential Revision: https://phabricator.services.mozilla.com/D2730
--HG--
extra : rebase_source : 4d46eee982e9868050f1201aba74b020045d9ec1
extra : histedit_source : 744948fa80ae8e3b18212e840843906577fd38ec
The taskgraph code for test-verify currently looks at locally changed files to
determine how many chunks should be run. This code exists so that
`mach try fuzzy` show the same chunks that would be run on a try push.
This changes it, so that local commts are only considered on try and when
called from try-select. This makes generating the taskgraph locally faster,
when not using `mach try`. It also makes test-verfiy not consider too many
files, if the try push happens to contain commits that have landed but havent
been pushed to try yet (i.e. the first push to try after a merge, or beta try
pushes).
Differential Revision: https://phabricator.services.mozilla.com/D2698
--HG--
extra : rebase_source : 68b1ea583730ff3086949aa6c7b6a1046b406d23
extra : histedit_source : 68bbc7ca2062c7f425353e6caf6b8959786dc42d
Currently, `mach try fuzzy` generates a taskgraph that is configured exactly
like the most recent push to mozilla-central. This isn't always desirabe, so
pass some configuration down, to allow the taskgraph to behave differently.
Differential Revision: https://phabricator.services.mozilla.com/D2729
--HG--
extra : rebase_source : 99d6958b33211697227e65df17edc1eb337f63a4
extra : histedit_source : 69b5ff6805bc8409340eb71323a1f6fc637259d7
