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 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 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 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 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
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
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
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
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
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
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
Add a new TextureClientData type, AndroidNativeWindowTextureData,
backed by a SurfaceTexture in single-buffer mode. It uses the
NativeWindow API, which provides producer-side access to the buffer.
This provides a DrawTarget which can be used to paint directly in to
the SurfaceTexture, which can then be composited using a SurfaceTextureHost.
Due to API restrictions it is not possible to read from a NativeWindow
while the corresponding SurfaceTexture has ownership of the
buffer. TiledContentClient now handles that by painting the additional
region that it cannot copy from the front buffer, if required.
MozReview-Commit-ID: 1NZq6MQqwFq
--HG--
extra : rebase_source : 9d1db721d4892f3df033d43127489a85421e8863
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
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
The caller of RenderHighPrecision and RenderLowPrecision doesn't look at the
variable that it passes as the aInvalidRegion parameter after the call, so any
modifications that would have happened to this variable don't matter.
MozReview-Commit-ID: B9PaXjZkxv2
--HG--
extra : rebase_source : fb66ae3170a9891fbb5d4d90aebf78230b8f9ce0
Currently the profiler mostly uses an array of strings to represent which
features are available and in use. This patch changes the profiler core to use
a uint32_t bitfield, which is a much simpler and faster representation.
(nsProfiler and the profiler add-on still use the array of strings, alas.) The
new ProfilerFeature type defines the values in the bitfield.
One side-effect of this change is that profiler_feature_active() now can be
used to query all features. Previously it was just a subset.
Another side-effect is that profiler_get_available_features() no longer incorrectly
indicates support for Java and stack-walking when they aren't supported. (The
handling of task tracer support is unchanged, because the old code handled it
correctly.)
