As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
--HG--
extra : moz-landing-system : lando
It's possible to trigger this assertion with asyncPaint = true and
bufferRotation != (0, 0). In this case though everything should work fine,
because we didn't start a new paint task, and we should be able to copy over
buffers. So we should be able to remove this assertion.
--HG--
extra : amend_source : d4cb9eddf48e08446469d2e1891f0e9ed3bb85d0
Now that we have C++14 support we can capture a move only object in a lambda expression.
--HG--
extra : rebase_source : 232639ba334520cf9d38d68190af8fdcd4aa454d
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
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 patch was generated using a simple sed script:
sed -i 's/ToUnknownRegion().GetBounds()/GetBounds().ToUnknownRect()/g' gfx/**/*.cpp gfx/**/*.h
Differential Revision: https://phabricator.services.mozilla.com/D3875
--HG--
extra : rebase_source : 4e9e7c9f2fb4ca60122712dd06632147cdec7195
In bug 1482415 a special check was added for the case where we fail to allocate
a buffer and started an async task. This papered over one crash for another
as ClientPaintedLayer also assumes that if there is an async task there is
a capture. It'd be best to just null out mAsyncTask and keep those checks
as is.
Differential Revision: https://phabricator.services.mozilla.com/D3520
--HG--
extra : rebase_source : 8cb2458f0a98795a6ece90b38a9c194c863bbd84
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 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 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 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 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 : 546d9838808320c51d9ceef0ed0ffcbb88a16269
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 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 : abad14bfee32ea2fd1626069f8229487d1f05015
When computing whether we have an intermediate buffer or not, which
in our case amounts to the inverse of deciding whether we want to use
a DirectMapTextureSource or not, we want to ensure that we don't use
one if the texture is too big to be a single texture in OpenGL. This
will default to using a TiledTextureImage. In a perfect world we
would build tiling logic into the client storage approach, but that
shouldn't block this.
MozReview-Commit-ID: 7Oi86oGis93
--HG--
extra : rebase_source : df9d314ef3d9a285bb10a9e21b87dc280a88fa84
This seems to be unused. Not sure if it's still left in here for
a reason or not.
MozReview-Commit-ID: 3wxaCDI7eCO
--HG--
extra : rebase_source : 25dda76dce892e580dbf31741e359d3a78f5742a
There's a lot going on here, but it all fits under the idea of
being able to communicate about texture locking statuses
without spinning on IsReadLocked. This is a bit of a trade -
we could just always allocate/grab a texture from the pool,
which would put a smaller cap on the amount of time we can
possibly spend when a texture is locked. However, this eats
up more CPU and memory than waiting on the textures to unlock,
and could take longer, especially if there were a large number
of textures which we just need to wait for for a short amount
of time. In any case, we very rarely hit the case where we
actually need to wait on the sync IPC to the compositor - most
of the time the textures are already unlocked.
There is also an async IPC call in here, which we make before
flushing async paints. This just causes the compositor to
check whether the GPU is done with its textures or not and
unlock them if it is. This helps us avoid the case where we
take a long time painting asynchronously, turn IPC back on at
the end of that, and then have to wait for the compositor
to to get into TiledLayerBufferComposite::UseTiles before
getting a response. Specifically this eliminates several talos
regressions which use ASAP mode.
Lastly, there seem to be no other cases of static Monitors
being used. This seems like it falls under similar use cases
as StaticMutexes, so I added it in. I can move it into its own
file if we think it might be generally useful in the future.
MozReview-Commit-ID: IYQLwUqMxg2
--HG--
extra : rebase_source : 4f05832f51dae6db98773dcad03cb008a80eca6c
The client side can't get the GL context in CompositorOGL. So, it can't know
the texture direct mapping capability directly. This patch adds the texture
direct mapping info in TextureFactoryIdentifier. Then, the client side could
get the info form the TextureFactoryIdentifier.
MozReview-Commit-ID: KEazDVg0p9Y
--HG--
extra : rebase_source : 09ce1065cd076a3a5dc276f93837d608443c60a1
When computing whether we have an intermediate buffer or not, which
in our case amounts to the inverse of deciding whether we want to use
a DirectMapTextureSource or not, we want to ensure that we don't use
one if the texture is too big to be a single texture in OpenGL. This
will default to using a TiledTextureImage. In a perfect world we
would build tiling logic into the client storage approach, but that
shouldn't block this.
MozReview-Commit-ID: 7Oi86oGis93
--HG--
extra : rebase_source : a5477abdfc7140c983fd23692beeb6529f1714d1
This seems to be unused. Not sure if it's still left in here for
a reason or not.
MozReview-Commit-ID: 3wxaCDI7eCO
--HG--
extra : rebase_source : 17c54842e57bcdb52254e65220dfc733356a5f37
There's a lot going on here, but it all fits under the idea of
being able to communicate about texture locking statuses
without spinning on IsReadLocked. This is a bit of a trade -
we could just always allocate/grab a texture from the pool,
which would put a smaller cap on the amount of time we can
possibly spend when a texture is locked. However, this eats
up more CPU and memory than waiting on the textures to unlock,
and could take longer, especially if there were a large number
of textures which we just need to wait for for a short amount
of time. In any case, we very rarely hit the case where we
actually need to wait on the sync IPC to the compositor - most
of the time the textures are already unlocked.
There is also an async IPC call in here, which we make before
flushing async paints. This just causes the compositor to
check whether the GPU is done with its textures or not and
unlock them if it is. This helps us avoid the case where we
take a long time painting asynchronously, turn IPC back on at
the end of that, and then have to wait for the compositor
to to get into TiledLayerBufferComposite::UseTiles before
getting a response. Specifically this eliminates several talos
regressions which use ASAP mode.
Lastly, there seem to be no other cases of static Monitors
being used. This seems like it falls under similar use cases
as StaticMutexes, so I added it in. I can move it into its own
file if we think it might be generally useful in the future.
MozReview-Commit-ID: IYQLwUqMxg2
--HG--
extra : rebase_source : 67f6fee8b89933561a48e6f7f531b6969893a574
The client side can't get the GL context in CompositorOGL. So, it can't know
the texture direct mapping capability directly. This patch adds the texture
direct mapping info in TextureFactoryIdentifier. Then, the client side could
get the info form the TextureFactoryIdentifier.
MozReview-Commit-ID: KEazDVg0p9Y
--HG--
extra : rebase_source : 425159494772431283138bbaa4574c6201a2bc59
There's a lot going on here, but it all fits under the idea of
being able to communicate about texture locking statuses
without spinning on IsReadLocked. This is a bit of a trade -
we could just always allocate/grab a texture from the pool,
which would put a smaller cap on the amount of time we can
possibly spend when a texture is locked. However, this eats
up more CPU and memory than waiting on the textures to unlock,
and could take longer, especially if there were a large number
of textures which we just need to wait for for a short amount
of time. In any case, we very rarely hit the case where we
actually need to wait on the sync IPC to the compositor - most
of the time the textures are already unlocked.
There is also an async IPC call in here, which we make before
flushing async paints. This just causes the compositor to
check whether the GPU is done with its textures or not and
unlock them if it is. This helps us avoid the case where we
take a long time painting asynchronously, turn IPC back on at
the end of that, and then have to wait for the compositor
to to get into TiledLayerBufferComposite::UseTiles before
getting a response. Specifically this eliminates several talos
regressions which use ASAP mode.
Lastly, there seem to be no other cases of static Monitors
being used. This seems like it falls under similar use cases
as StaticMutexes, so I added it in. I can move it into its own
file if we think it might be generally useful in the future.
MozReview-Commit-ID: IYQLwUqMxg2
--HG--
extra : rebase_source : 3624ad04aa01dac1cd38efb47764dc3a8fbd5fbd
The client side can't get the GL context in CompositorOGL. So, it can't know
the texture direct mapping capability directly. This patch adds the texture
direct mapping info in TextureFactoryIdentifier. Then, the client side could
get the info form the TextureFactoryIdentifier.
MozReview-Commit-ID: KEazDVg0p9Y
--HG--
extra : rebase_source : 1d7c0700d1f24236102de467efd84af093687ab5
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 the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
--HG--
extra : rebase_source : 29ebd6a85dd49ee263d50e3674eec4957ac5f12a
extra : histedit_source : 1aa9f4f31b5bff6736e0c0e576a5611880d0ab33
This commit adds the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
--HG--
extra : rebase_source : cecb7149f50b2abe7a827dc20f1e8b8ade199258
extra : histedit_source : 581f8f38fc8335575d7275b903a8e1d6a9e5a369
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
Just a cleanup patch, this function would be cleaner without the
nesting.
MozReview-Commit-ID: DD48E2HSQOL
--HG--
extra : rebase_source : 79cf6b3eee00149fa5993c10bd69649633307fee
extra : histedit_source : 1fde6b0291acddcf73569b2e43757030c38d9e69
In order to have useful Wayland builds we need ability to switch
between GL backends run-time - to use EGL backend for Wayland and GLX backend for X11.
GL_PROVIDER_GLX is used exclusively for GLX GL backend, so let's replace GL_PROVIDER_GLX
build-time check by more general MOZ_X11 check which determines X11 dependent code
and it's valid for both X11 and Wayland builds.
MozReview-Commit-ID: HYobrHveoaP
--HG--
extra : rebase_source : 2d359355ee747f5898d27d8a28d66114f4135f5b
This commit moves FlushAsyncPaints to EndTransactionInternal, which allows
us to continue async painting during DLB and FLB. We still flush async paints
before rasterizing into layers as we aren't triple buffered.
--HG--
extra : amend_source : 6ee4f511008c60fe1f52f7a260ef7d5b5e3c0c92
This is the other half of the commit renaming the TileUnit to TileCoordUnit. It
also includes some small style cleanups.
--HG--
extra : rebase_source : ebf7a275bed518d1419a2e3c23b67f36601a1089
SingleTiledContentClient has it's own file and this helps make ContentClient slimmer.
--HG--
rename : gfx/layers/client/TiledContentClient.cpp => gfx/layers/client/MultiTiledContentClient.cpp
rename : gfx/layers/client/TiledContentClient.h => gfx/layers/client/MultiTiledContentClient.h
extra : rebase_source : 7c70cfa04f9faa840b2aa8a81680486e4ed0245e
TileCoord is a (very slightly) better name for this unit in my opinion, and I'd
like to add a TileBuffer unit in the future which might get confused if there
is an unprefixed Tile unit.
--HG--
extra : rebase_source : 968f508f2195c12fd4840e2415130b1b36fd3e29
This appears to be unused, and is just needlessly calculating something.
MozReview-Commit-ID: Jpm9sBwJBfT
--HG--
extra : rebase_source : 0a743c6ed0f79b92715d2f902e9a607ccad0d1ea
It can happen often where we reuse the front buffer for a long paint, and then
the next frame we see that it is still locked, and need to allocate a new buffer
from the texture pool. If this happens we don't need to repaint the new buffer
because the old buffer is still around, but we do need to copy it over and
upload it to texture sources. It seems better to just hold onto the back buffer
and let it accumulate more invalid regions.
MozReview-Commit-ID: 2DQjwAX7ZmM
--HG--
extra : rebase_source : 3077952d3ef56deea6af68492f71bb114d96d84a
When we are creating a new back buffer we mark the whole region as being
invalid. This will cause us to paint extra in certain circumstances where
the visible region is a subset of the tile space.
MozReview-Commit-ID: BayRu0mV39O
--HG--
extra : rebase_source : b7eb40408faca5fc3fbc3e53263de7d262af35d5
We discard and copy over data from the old tile when we resize a single tiled content client. For some reason
we were not removing that region we successfully copied from the invalid region we would then set on the tile.
This would cause us to do more work on following frames. For some other reason we were removing that region
from the region we'd clear for non-opaque tiles. This commit changes it so we remove it from both.
MozReview-Commit-ID: DIu1Y3jzV7Z
--HG--
extra : rebase_source : 9c06482798823cf9ecb9be4937c6af9dd1ece6f2
This changes the lifecycle and API for TextureReadLock to fix file descriptor exhaustion
crashes. These changes are partially superficial and mostly align the API of TextureReadLocks
with their actual usage.
The changes are:
1. Create the TextureReadLock in the TextureClient constructor so it's available before IPC creation
a. This is superficial as EnableReadLock was always called before IPC creation
2. Send the ReadLockDescriptor in the PTextureConstructor message and close the file handle
3. Receive the ReadLockDescriptor in TextureHost and close the file handle
4. Send a boolean flag in layer transactions if the texture is read locked instead of a descriptor
5. Use a boolean flag in TextureHost to determine if the ReadLock must be unlocked instead of a nullptr
I believe that we can remove the InitReadLocks code from LayerTransaction as that was added to
prevent file descriptor limits in IPDL messages and is no longer needed with this change. But
that is a non-essential change and this patch is already big enough.
MozReview-Commit-ID: DzHujrOQejH
--HG--
extra : rebase_source : 3bdd7c9bc8edfdc386faad8a9e59ad7dc18ed91d
It looks like the call chain is called ScheduleComposite on the client
LayerManager API, but then for some reason the functions in the IPDL
bridges are called ForceComposite, and then they eventually call the
ScheduleComposition function on the CompositorVsyncScheduler. This is
silly, so I renamed the IPDL bridge functions to ScheduleComposite as
well to be consistent.
MozReview-Commit-ID: D7bWpASaEtb
--HG--
extra : rebase_source : ecb0494d9461bd4ada48bfb602e7b518f0601c1b
CompositorBridgeChild may be lost at any time due to a GPU process
crash. Additionally it may be already destroyed due to shutdown being
initiated. For FlushAsyncPaints, we can safely ignore the missing child
because the subsequent operations will generally fail and we will
recover when the GPU process is respawned (or switched to the UI
process).
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 patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
Additionally, various C++ code and style cleanup
MozReview-Commit-ID: 7BCtQzFGaOc
--HG--
extra : rebase_source : 77598165c0f6ad9f04c8a09985c79df82f2732e4
Currently ContentClient will attempt to create a buffer of any size
that Layers requires it to. If that fails it will then warn if the
requested buffer was an unreasonable size. This change makes it so
that we check whether the size is reasonable first, and do not attempt
to create the buffer if it is unreasonable.
Previously the operating system would have managed to allocate some
buffers that we deem unreasonable, but at the cost of the system
becoming unresponsive. Now, some large buffers which would previously
have been created won't be, but the chances of the system becoming
unresponsive should decrease.
Ideally Layers wouldn't request buffers of these sizes in the first
place - there are measures in place to try to prevent it, and more work
is certainly required. However, this will act as a last ditch defence.
MozReview-Commit-ID: 7WCqEwkmViy
CaptureTiledPaintState will execute all buffer copy operations first,
followed by all buffer clears. This works for MultiTiledContentClient
as it does those operations in that order. SingleTiledContentClient
can do copies, followed by a clear, followed by some copies.
If the clears are hoisted after the copies, graphical corruption can
happen. I think the easiest way to fix this is to move the clear
after the copies and sub out the region that has been successfully
copied.
MozReview-Commit-ID: EfMVmCzyy8w
--HG--
extra : rebase_source : aa9dfa0e38b0173100da99d7111a8c412c628c60
We collect the back buffer texture clients to preserve while
async painting is happening, but if we do a buffer copy we
should preserve front buffer clients as well.
MozReview-Commit-ID: 9KbXkqjm34v
--HG--
extra : rebase_source : fce09b7b6ab094b896acc9648bfa698752f0feac
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
There's no need to perform the format test within the loop, so we can separate the different cases as needed.
Also copy the entire pixel data in one go, by using C types.
The skip value definition doesn't specify if it's in bytes, or in "pixels". We will assume the later. There are currently no decoders returning HDR content with a skip value different than zero anyway.
MozReview-Commit-ID: KTwYuNKJq3R
--HG--
extra : rebase_source : 3f1989c37ebdab6a60605815a961eda7286c423c
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 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
Skip files under intl/icu/ because they're imported from third party.
DONTBUILD because this is a whitespace-only change.
MozReview-Commit-ID: GSd6oeFSTO7
--HG--
extra : rebase_source : 38c20bf6099c18b2fcb4c324d470b279addf8891
The core of this change is in gfxContext.*:
- change gfxContext::CurrentMatrix() and gfxContext::SetMatrix() to
return and take a Matrix respectively, instead of converting to
and from a gfxMatrix (which uses doubles). These functions therefore
will now match the native representation of the transform in gfxContext.
- add two new functions CurrentMatrixDouble() and SetMatrixDouble() that
do what the old CurrentMatrix() and SetMatrix() used to do, i.e.
convert between the float matrix and the double matrix.
The rest of the change is just updating the call sites to avoid round-
tripping between floats and doubles where possible. Call sites that are
hard to fix are migrated to the new XXXDouble functions which preserves
the existing behaviour.
MozReview-Commit-ID: 5sbBpLUus3U
We do the same in FinalizeFrame, so we should do it here.
MozReview-Commit-ID: JTKDj8yrtI2
--HG--
extra : rebase_source : 6ba114c6734990dcb62e361889d1b2cf2b5ad7dc
extra : intermediate-source : 76bf99decf0906f0a6a4ad99539fd40f97c4539f
extra : source : fb9b0524428307c4ee097894e37879339df47579
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
To sync the back buffer with the front buffer, we set the back buffer rect and
rotation to the front buffer's, and then copy over the pixels that different.
We used to do the updating of the rect and rotation before BeginPaint, but that
isn't necessary and we can move it to be with the copying of pixels.
MozReview-Commit-ID: HzBKvMZkn1
--HG--
extra : rebase_source : 053e55df273d0d89327b80bc599ee05a020f6fef
extra : intermediate-source : 467532fd5b7a2385ba0dbdb9201e28e8f2b4a583
extra : source : 3d0da65640964e5a0565b5e7b7646cf719ce1449
This commit is an optimization for double buffering that delays the creation of
a back buffer until we know what kind of content type it needs to be.
Before this commit, we would EnsureBackBufferIfFrontBuffer before BeginPaint,
then in BeginPaint we could determine that we actually needed a different kind
of buffer because the content changed type, and recreate it.
This was needed because BeginPaint would copy the old front buffer to the buffer
created by EnsureBackBufferIfFrontBuffer, and then if anything failed or we had
determined we couldn't reuse the buffer, we would create a new one and copy that
"temporary" back buffer over, and use the new one.
This is unnecessary because we only need read access on that "temporary" back
buffer, and so we can just use the current front buffer instead.
This optimization only affects the double buffered case, and the single buffered
or basic cases should remain the same.
Note: Because we now need the front buffer for copying into the new back buffer,
we cannot Clear() it away in some error cases.
Note: The code in FinalizeFrame assumes that the back and front buffer have the
same size. This was implicitly enforced before, and now needs to be explicitly
enforced. This commit tries to preserve the exact same behavior, although the
restriction should be removed as long as the back buffer is large enough for
the visible region.
MozReview-Commit-ID: 2hyrrUhA4zO
--HG--
extra : rebase_source : 5db62a4d24383c7d64e127880a3bee7ff76dada1
extra : intermediate-source : dce585be0737f3c9b6b241afb0851d85fb9453c9
extra : source : 926af2eca400cf8a16777813ceb586b1d3be7d68
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
We do the same in FinalizeFrame, so we should do it here.
MozReview-Commit-ID: JTKDj8yrtI2
--HG--
extra : rebase_source : 9f900a4641df71a8da79a406cc89407a3553221f
extra : intermediate-source : de3aa5583481a3680e3d0cfdbe6b55916f0ef58a
extra : source : fb9b0524428307c4ee097894e37879339df47579
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
Jean-Yves Avenard
Narcis Beleuzu
Brindusan Cristian
Ryan Hunt
Ciure Andrei
Jamie Nicol
Bas Schouten
Gabriele Svelto
Nicolas Silva
Brian Hackett
Andi-Bogdan Postelnicu
Kartikaya Gupta
Imanol Fernandez
Doug Thayer
Cosmin Sabou
Margareta Eliza Balazs
sotaro
Csoregi Natalia
Emilio Cobos Álvarez
Markus Stange
Noemi Erli
Martin Stransky
Sebastian Hengst
Tristan Bourvon
Ryan VanderMeulen
Matt Woodrow
Milan Sreckovic
Andrew Osmond
JerryShih
Hiroyuki Ikezoe
Chris Peterson
Dorel Luca
Andreea Pavel
Alexis Beingessner
Andrew McCreight
Kevin Chen
David Anderson
Ting-Yu Lin