* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--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 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 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
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
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
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
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
