And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
Now that we have C++14 support we can capture a move only object in a lambda expression.
--HG--
extra : rebase_source : 232639ba334520cf9d38d68190af8fdcd4aa454d
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 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 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 : c8f628180a3d908c8851e5c576296f903b9b255d
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 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
PaintOffMainThread uses didUpdate to track whether we queued work on the paint
thread and also if we painted new content into the buffer and need to update
the content client. These are independent and should have different flags. We
may flip the buffers incorrectly if we don't do this.
This is also important because ContentClient can return a BufferState even if
there are no operations and no backing buffer, causing a crash in Updated().
MozReview-Commit-ID: C6OW3jDJ3B4
--HG--
extra : rebase_source : 4545b70db1a608fdf736c6ff4c02836c00c80e93
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 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 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
I believe this is the only case where we miss calling EndLayerTransaction,
but still had queued async paints. This wasn't an issue before, because
the following transaction would then do the synchronization. But I'd
like to use EndLayerTransaction for a profiler mark, so we should call
it unconditionally.
MozReview-Commit-ID: 9rUXBzCZaLO
--HG--
extra : rebase_source : ba360f2451190cf38745121d4dc32f4ed8d1bfe2
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
Now that BeginPaintBuffer and BeginPaint are both implemented by content client,
I think it makes sense to just merge them into one method. This simplifies the
interface clients have to use.
MozReview-Commit-ID: 8bjH6WcpZS9
--HG--
extra : rebase_source : 1b22549c03299e1b1b9ba8a04f3c3e428577e062
This commit does some more cleanup on the content client class hierarchy.
Some methods were virtual or instance methods when they didn't need to be.
MozReview-Commit-ID: 2y2D3zYtYvM
--HG--
extra : rebase_source : 41649182f1d99daae600568722f0b8615d27fe26
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
This commit is the guts of the refactoring.
This commit removes rotated content buffer, and moves the necessary
functionality to content client. All content clients now do not inherit from
rotated content buffer, but contain a refptr to a rotated buffer.
For the basic content client, this is a DrawTargetRotatedBuffer.
For the remote content client, this is a RemoteRotatedBuffer.
The double buffered content client contains an additional RemoteRotatedBuffer
for the front buffer.
Each derived class of content client only needs to implement a method to
create its own rotated buffer. The rest is handled by the base content
client. The remote content clients still override some additional methods
to sync buffers and do IPC.
MozReview-Commit-ID: B9vcSi8UYhm
--HG--
extra : rebase_source : f4b1dcb3cd06f7d0da7ed85e5d3f4bf5ec445e7f
Miscellaneous cleanup, PaintState doesn't need to know this as no one uses
this information outside of the content client classes.
MozReview-Commit-ID: 6K8LxEPvp4V
--HG--
extra : rebase_source : 8bef61a47f423dd83ac9ea39b84f064bd7681e0c
This class doesn't seem to be necessary and only complicates the class
hierarchy.
MozReview-Commit-ID: 6dRXce1vB9T
--HG--
extra : rebase_source : 10b398f952979c4b0db4b95bd3a460a0cf00a9f8
Now that BeginPaintBuffer and BeginPaint are both implemented by content client,
I think it makes sense to just merge them into one method. This simplifies the
interface clients have to use.
MozReview-Commit-ID: 8bjH6WcpZS9
--HG--
extra : rebase_source : c2aad6cd9d85f7dd09652ee253683f03825e95c6
This commit does some more cleanup on the content client class hierarchy.
Some methods were virtual or instance methods when they didn't need to be.
MozReview-Commit-ID: 2y2D3zYtYvM
--HG--
extra : rebase_source : ebd137e4a1ee8eba10467e987bd2d91ea44ca5a2
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
This commit is the guts of the refactoring.
This commit removes rotated content buffer, and moves the necessary
functionality to content client. All content clients now do not inherit from
rotated content buffer, but contain a refptr to a rotated buffer.
For the basic content client, this is a DrawTargetRotatedBuffer.
For the remote content client, this is a RemoteRotatedBuffer.
The double buffered content client contains an additional RemoteRotatedBuffer
for the front buffer.
Each derived class of content client only needs to implement a method to
create its own rotated buffer. The rest is handled by the base content
client. The remote content clients still override some additional methods
to sync buffers and do IPC.
MozReview-Commit-ID: B9vcSi8UYhm
--HG--
extra : rebase_source : a727d5548b0167eb12676837b173355eb0dd38a5
Miscellaneous cleanup, PaintState doesn't need to know this as no one uses
this information outside of the content client classes.
MozReview-Commit-ID: 6K8LxEPvp4V
--HG--
extra : rebase_source : 931f7726d2f8f1f5ab32b5cf8f9030aa39a64bff
This class doesn't seem to be necessary and only complicates the class
hierarchy.
MozReview-Commit-ID: 6dRXce1vB9T
--HG--
extra : rebase_source : 71591b44c68f9c8b73c7aadb6be245caaec0fbb5
Sylvestre Ledru
Jean-Yves Avenard
Gurzau Raul
Bas Schouten
Ryan Hunt
Brindusan Cristian
Andreea Pavel
NARCIS BELEUZU
Daniel Holbert
Sebastian Hengst
Mason Chang