Now that we have C++14 support we can capture a move only object in a lambda expression.
--HG--
extra : rebase_source : 232639ba334520cf9d38d68190af8fdcd4aa454d
These method names and ordering have gotten out of sync because of
the recent churn.
Differential Revision: https://phabricator.services.mozilla.com/D3288
--HG--
extra : rebase_source : 42bceaeb66a0df4808981b8c9cb0ed70b23f5a30
extra : histedit_source : 228024efe8de4e149f7e7ca66a2bb078bba820ce
This may have been needed at some point, but all the important code for
EndLayerTransaction is in CompositorBridgeChild behind a lock, so this
should be safe.
--HG--
extra : rebase_source : bda4080bc04afa95954732050df7bd25c8177752
extra : histedit_source : 9386583dd923bf0ae44ff783d3ef1c6692944c77
There should only ever be at most four TextureClients here, so
allocated a vector seems wasteful.
--HG--
extra : rebase_source : 6b0f9f7749461eb39cd3c6c6bf7917152ffc9aab
extra : histedit_source : b5539d02c294596a5147dc55b417ef7970f8c0cd
This was needed when there were multiple types of CapturedPaintStates but
is not anymore.
--HG--
extra : rebase_source : 3648edccca7c73e3e3aa7a5c3e0d48d12d6324c5
extra : histedit_source : 021814c10b6578970c3a6d234c1e6641ad26b095
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 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 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 : 2f63464c1f8ca03992700b33838c4aa56608f872
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 : 1b5259cca6520761ae99e64157d047441b90b563
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 : 16a4b87263f28b32f5bcb5fd6d9756548f137e11
This commit ports over the last remaining operation for tiling that doesn't work
on the paint thread.
The difficult part for edge padding is that it is done outside of ValidateTile
so it doesn't have an associated CapturedTilePaintState to be added to as an
operation. We need it to be in the same paint state so that it's guaranteed
to be run after painting has finished.
This commit changes edge padding to instead be decided inside of ValidateTile
and either sent to the paint thread if there is OMTP or executed right away.
MozReview-Commit-ID: JDD4rH1fVwW
--HG--
extra : source : 9b0a54842d3169960a606fa1dd335acf6aa70dbe
extra : intermediate-source : bcbab66c16c5cc2b917f12b4481bbbb8fe3eb097
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 implements recording of buffer preparing commands for MultiTiledContentClient
and replaying it on the paint thread.
The order of locking for tiling is important and for buffer copying the front
buffer needs to be attempted to be locked before the back buffer. This means
we can't do this on the paint thread like we do for ContentClient, so instead
I've changed the OpenMode::ASYNC to be a flag that can be applied to
OpenMode::OPEN_READ as well as WRITE, as it looks like we can apply the same
logic for READ as WRITE.
MozReview-Commit-ID: ED6eeYx8dUV
--HG--
extra : rebase_source : dd8d14f469f2a7d4f43c0a41373a6848f57f4b39
This commit modifies MultiTiledContentClient to record drawing commands and
replay them to the tiled draw target on the paint thread when OMTP is enabled.
MozReview-Commit-ID: 22zL3c4NZvu
--HG--
extra : rebase_source : f8256b678da683da76edc02769dd4d0ebe234e09
This commit reverts DoubleBufferedContentClient to creating a back buffer
if there is an existing front buffer. This reverts back to a sequence of a
finalize frame, unrotate, and initialize new back buffer. When we are
not async painting we do each buffer operation immediately. If we are
async painting, then we collect all of the buffer operations and perform
them on the paint thread.
Note on locking: The destination for buffer copies must always be opened
with the async write flag, and the source must be unlocked.
MozReview-Commit-ID: Gu4EcblY7Sg
--HG--
extra : rebase_source : ddbd85202aaa1e79ab56c76a055561f0d37d775a
This commit does the work of actually dispatching the recorded buffer operations
to the paint thread, and removing some main thread asserts from TextureClient.
MozReview-Commit-ID: CN3RoQPz9fP
--HG--
extra : rebase_source : 08ae6cf8445ef0a757efc54175768c2fa9bb1685
extra : intermediate-source : 0fc2414f146d8f5d08c97e5b7eedb25c5632ab2d
extra : source : e9349ad2f1f8fec862b1d2271d0d8f25ad0814d4
This commit adds a CapturedBufferState which is used to record all the operations
that are necessary for preparing the buffers. The commands are then instantly
executed to preserve the same behavior, but in the following commit they will
be dispatched to the paint thread.
Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made
for sending to the paint thread. This complicates the code for AdjustTo as it can
fail naturally and the buffer parameter changes are needed later in BeginPaint.
So the code for AdjustTo is split up a bit to accomodate that.
MozReview-Commit-ID: FwSwFay887o
--HG--
extra : rebase_source : 70dd8a055aaa13586810030978409d1a89c39081
extra : intermediate-source : f235b12eda6efe0bdec8e6590d813738f53ffe82
extra : source : cb6507b560aaad188fc83a47b664aaa5692a0acd
This commit does the work of actually dispatching the recorded buffer operations
to the paint thread, and removing some main thread asserts from TextureClient.
MozReview-Commit-ID: CN3RoQPz9fP
--HG--
extra : rebase_source : 9aeb3a727a930638aeb47a45a358769f1338d844
extra : source : e9349ad2f1f8fec862b1d2271d0d8f25ad0814d4
This commit adds a CapturedBufferState which is used to record all the operations
that are necessary for preparing the buffers. The commands are then instantly
executed to preserve the same behavior, but in the following commit they will
be dispatched to the paint thread.
Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made
for sending to the paint thread. This complicates the code for AdjustTo as it can
fail naturally and the buffer parameter changes are needed later in BeginPaint.
So the code for AdjustTo is split up a bit to accomodate that.
MozReview-Commit-ID: FwSwFay887o
--HG--
extra : rebase_source : 376f9a7184bdce2cc405e4608d38b8505aafc2d6
extra : source : cb6507b560aaad188fc83a47b664aaa5692a0acd
This commit does the work of actually dispatching the recorded buffer operations
to the paint thread, and removing some main thread asserts from TextureClient.
MozReview-Commit-ID: CN3RoQPz9fP
--HG--
extra : rebase_source : c14b9da390e88907e184409404c5c21b5fe23dff
This commit adds a CapturedBufferState which is used to record all the operations
that are necessary for preparing the buffers. The commands are then instantly
executed to preserve the same behavior, but in the following commit they will
be dispatched to the paint thread.
Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made
for sending to the paint thread. This complicates the code for AdjustTo as it can
fail naturally and the buffer parameter changes are needed later in BeginPaint.
So the code for AdjustTo is split up a bit to accomodate that.
MozReview-Commit-ID: FwSwFay887o
--HG--
extra : rebase_source : 3e8b49d5931d853857dd1b2eeff914465251f613
This commit adds instrumentation and some asserting to track a "paint group",
which is essentially the first PaintThread::AsyncPaintContents until
PaintThread::AsyncEndLayerTransaction.
I didn't add an AsyncBeginLayerTransaction and use that to start a "paint group"
as I think it makes sense to not have a paint marker if we don't do
any painting.
MozReview-Commit-ID: AlSsUUF5ZOH
--HG--
extra : rebase_source : 84d9feaf5aac39fb9ce32984efda704fa2a68838
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
CapturedPaintState::mTarget is actually a dual draw target to the black and
white draw targets, so this code will have the white draw target cleared black
and then white. This isn't incorrect, it's just wasteful.
MozReview-Commit-ID: ItgiSmegPK6
--HG--
extra : rebase_source : 13553bb1ec3c4b96a585ba4af4e8ff31f485e89e
CapturedPaintState::mTarget is actually a dual draw target to the black and
white draw targets, so this code will have the white draw target cleared black
and then white. This isn't incorrect, it's just wasteful.
MozReview-Commit-ID: ItgiSmegPK6
--HG--
extra : rebase_source : 9c3c88f463087a75383f1940ddeef6bb68ec35c4
