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 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 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
BufferContentType and BufferSizeOkFor make more sense as general functions for
any RotatedBuffer, and this helps out in a later patch.
MozReview-Commit-ID: EAVodvl4WTu
--HG--
extra : rebase_source : 122b6466ef0194d6ff682d677db01312c9e27a2a
extra : intermediate-source : b971c1aa5a78c17d49d1d64389516437024be72a
extra : source : b57a3f0d08478f094328b5a50c57eed35798fdf0
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
BufferContentType and BufferSizeOkFor make more sense as general functions for
any RotatedBuffer, and this helps out in a later patch.
MozReview-Commit-ID: EAVodvl4WTu
--HG--
extra : rebase_source : 6b3406713414a5fe5c1ace6cd0db86c811557323
extra : source : b57a3f0d08478f094328b5a50c57eed35798fdf0
Use MOZ_CRASH, MOZ_CRASH_UNSAFE_OOL, or MOZ_CRASH_UNSAFE_PRINTF instead.
MozReview-Commit-ID: 1kCCHMlgbGP
--HG--
extra : rebase_source : 2f07ced16bccebf30cd3b2b5fea35e9868d32dad
extra : source : 0bf2c8425b828e71de55dd175fd0dad635b4e67d
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
BufferContentType and BufferSizeOkFor make more sense as general functions for
any RotatedBuffer, and this helps out in a later patch.
MozReview-Commit-ID: EAVodvl4WTu
--HG--
extra : rebase_source : 22c004e81257bf2d31438972c17b7b4f61532b23
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
UpdateDestinationFrom actually only uses a rect, so it's best to not be
misleading and force the clients of it to do the conversion.
MozReview-Commit-ID: EsUv3apqnku
--HG--
extra : rebase_source : 02fdd8f7ede0e1c4712a721e14a4ad809b6dff14
This organizes the rotated buffer declarations and adds some documentation.
MozReview-Commit-ID: 5r24RiUMM6o
--HG--
extra : rebase_source : 5279f7f754d41b06576f852672450d1d4bca803f
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
This commit splits off the part of BeginPaint that makes the decision about
whether to keep the buffer, its surface type, its content type, and the regions
to invalidate or paint.
MozReview-Commit-ID: JcPlv8GiRpA
--HG--
extra : rebase_source : 1867264e82fde108ff52ea295907851ce25dbff5
This commit adds a method to rotated buffer to perform the adjusting to the new
destination rect, and potential unrotating that may need to happen. The goal of
this is to simplify and prepare BeginPaint to be moved to content client.
MozReview-Commit-ID: B4qeZqLjORR
--HG--
extra : rebase_source : 1878d562df2904fff8fbbf805e1d6b5d8533e337
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 adds a new implementation of rotated buffer, which is backed by draw
targets. This will be the rotated buffer that basic content clients use.
MozReview-Commit-ID: Knn79yEFnxN
--HG--
extra : rebase_source : 49f72c0974a6ba9715e9b0cea765ba45660475c5
The front buffer for a double buffered content client is really just another
rotated buffer, so it can simplify the code to use the class we just added.
The goal is to have the back and the front buffer using remote rotated buffers,
but this is a good first step.
Note: The front buffer is represented as a Maybe<RemoteRotatedBuffer> in this
commit, but in the future it will be a RefPtr. That can't be done yet, because
rotated buffer can't implement refcounting in addition to compositable client.
MozReview-Commit-ID: Czk3otkf1pb
--HG--
extra : rebase_source : e6b5e66f47ccdc1c75a3a2a9c73efc2b82a25890
This adds a new implementation of rotated buffer, which is backed by texture
clients. This will be the rotated buffer that remote content clients use.
MozReview-Commit-ID: 3Y776uk5mFG
--HG--
extra : rebase_source : f193eec8af60a6e70345312cda0ce86cac70a7a2
Similar to the previous patch, more functionality can be moved to rotated
buffer and out of rotated content client.
MozReview-Commit-ID: FNqfonyBBq9
--HG--
extra : rebase_source : cfc9c10d31baa48163107d0cf36c28a8ffda4ebb
UpdateDestinationFrom is a useful method for any rotated buffer. This will be
needed when content clients are no longer rotated buffers.
Note: EnsureBuffer and EnsureBufferOnWhite were moved out of
UpdateDestinationFrom because I'd like to kill those methods, and so the calls
were moved to all users of UpdateDestinationFrom.
MozReview-Commit-ID: 2e3HhUsZ6iw
--HG--
extra : rebase_source : 73532ad481a4c0b1af63c4647e0e8f7f4c5b2dc3
UpdateDestinationFrom actually only uses a rect, so it's best to not be
misleading and force the clients of it to do the conversion.
MozReview-Commit-ID: EsUv3apqnku
--HG--
extra : rebase_source : 6ee0f7454ac2ea21618a62a9ab906857384d0fdf
This organizes the rotated buffer declarations and adds some documentation.
MozReview-Commit-ID: 5r24RiUMM6o
--HG--
extra : rebase_source : 28045e2d6b19db1f31796b7119717d417ee2dd34
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
Sylvestre Ledru
Ryan Hunt
Brindusan Cristian
Andreea Pavel
Chris Peterson
NARCIS BELEUZU
Daniel Holbert
Sebastian Hengst