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
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 : a34e50a4d7664e3134f9da06b10f1908aa0d9d60
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 : 2ddaa7d7d250475cf68524ad2151d8bcc7101013
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 : 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
Bug 1092294 introduced a regression in to the code to copy from
the discarded front buffers to the new backbuffers in
SingleTiledContentClient. The aim was to ensure that if locking the
the frontbuffers failed, meaning the region could not be copied, that it
would be painted instead. However due to incorrect logic the
region would both be copied and painted in cases where
there was no onWhite buffers.
To fix this we take both locks (frontLock, and frontOnWhiteLock if
required) up front, so that we either copy both buffers or neither.
MozReview-Commit-ID: 3iepOuweruk
--HG--
extra : rebase_source : 2e2f951c3315f2809191f43a9d5ec4a939c82724
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
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 : b5f5a0c46c225b8d2fbdd1891a16f3c0812382eb
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.
MozReview-Commit-ID: 2hyrrUhA4zO
--HG--
extra : rebase_source : 8eb7f992758d2e1db47eb88fe8d31651b335be6d
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 commit adds instrumentation and some asserting to track a "paint group",
which is essentially the first PaintThread::AsyncPaintContents until
PaintThread::AsyncEndLayerTransaction.
I didn't add an AsyncBeginLayerTransaction and use that to start a "paint group"
as I think it makes sense to not have a paint marker if we don't do
any painting.
MozReview-Commit-ID: AlSsUUF5ZOH
--HG--
extra : rebase_source : 84d9feaf5aac39fb9ce32984efda704fa2a68838
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
Even if we cannot reuse the back buffer, we still use it to initialize the new back buffer.
The correct condition for detecting changes to buffer mode should only care if there is a
buffer, not if we decided to reuse it.
If the buffer mode has changed to component alpha, we need to invalidate and repaint everything
because we won't be able to copy over content to the new buffer correctly.
I believe this is a regression from the refactoring that created this function from
RotatedContentBuffer::BeginPaint.
MozReview-Commit-ID: H9G7GxqekLt
--HG--
extra : rebase_source : afb3321694ce3f1b54ad4dce28b4a7c7c7b47904
extra : amend_source : fdef1994514fcc9b9f2e952767a785841e9ddda0
extra : histedit_source : 3e8324255f516094c242ab3ec0688d2285c85a99
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
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "// \* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
####
old="// \* This Source Code Form is subject to the terms of the Mozilla Public"
new=" \* This Source Code Form is subject to the terms of the Mozilla Public"
sed -i s%"^$old"%"$new"% $1
####
MozReview-Commit-ID: Ihx0EAOkT2g
--HG--
extra : rebase_source : 4dc97f234495e3ec1f4904e91d43d00fd3810626
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "^\* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
line1="\* This Source Code Form is subject to the terms of the Mozilla Public"
line2="\* License, v\. 2\.0\. If a copy of the MPL was not distributed with this"
line3="\* file, You can obtain one at http://mozilla\.org/MPL/2\.0/\. \*/"
# Insert 1 space at beginning:
sed -i s%"^$line1"%" $line1"% $1
sed -i s%"^$line2"%" $line2"% $1
sed -i s%"^$line3"%" $line3"% $1
###
MozReview-Commit-ID: HXBMrfnhlVr
--HG--
extra : rebase_source : de4c78563711f8366e2978c5199a5041875fbe38
mInAsyncPaint is only needed because the code using CreateBuffer expects the
buffer to be locked when it is returned. This isn't necessary because we can
now lock in BeginPaint.
MozReview-Commit-ID: 8WazvBKMbvb
--HG--
extra : rebase_source : d41fd1261565800b2d35dc531958b85eacdf4463
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
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 could be a part of the previous commit, but I omitted it to keep the size
down. Just some updates to comments and documentation.
MozReview-Commit-ID: HkCOSIQhBNv
--HG--
extra : rebase_source : bd94fa88d384123219528a6cf34c86e17f9de201
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
Miscellaneous cleanup, ContentClientSingleBuffered doesn't need to track if
the front and back buffer differ.
MozReview-Commit-ID: IvAw0b92jsh
--HG--
extra : rebase_source : 8660ea8c3dfa8d34789e8f9b9ad6a58726879e49
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
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
This class doesn't seem to be necessary and only complicates the class
hierarchy.
MozReview-Commit-ID: 6dRXce1vB9T
--HG--
extra : rebase_source : 10b398f952979c4b0db4b95bd3a460a0cf00a9f8
mInAsyncPaint is only needed because the code using CreateBuffer expects the
buffer to be locked when it is returned. This isn't necessary because we can
now lock in BeginPaint.
MozReview-Commit-ID: 8WazvBKMbvb
--HG--
extra : rebase_source : ec59ca27e88257bd8e6d384685bee8227f545b31
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
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 could be a part of the previous commit, but I omitted it to keep the size
down. Just some updates to comments and documentation.
MozReview-Commit-ID: HkCOSIQhBNv
--HG--
extra : rebase_source : 665b6bbe18dcd409809d33e1be37a56c0dc304d7
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
Miscellaneous cleanup, ContentClientSingleBuffered doesn't need to track if
the front and back buffer differ.
MozReview-Commit-ID: IvAw0b92jsh
--HG--
extra : rebase_source : c6b2d91666338f1d222f783b7a14e9d3b0ad6802
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 : b7cc399643295bb63efa86739f3dae29d3375ae6
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 : fce8c6212321e6e25dc414c517a28e1e3c747c25
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 : dd8f5a52808924a64ea0eb17359b6b749426b64e
This class doesn't seem to be necessary and only complicates the class
hierarchy.
MozReview-Commit-ID: 6dRXce1vB9T
--HG--
extra : rebase_source : 71591b44c68f9c8b73c7aadb6be245caaec0fbb5
Because it just doesn't control any behaviour within the profiler, and it just
duplicates gfxPrefs::LayersDumpTexture().
With this gone, PROFILER_FEATURE_ACTIVE can also be removed.
--HG--
extra : rebase_source : d6718894b8a9332cf73729ea6b7bd2de348817bd
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.
- This patch is the same as one from Bug 1382104 (Remove IsMirror concept
in favor of checking forwarder).
- It is safe to uplift this patch without the rest of Bug 1382104 as long
as the remaining Bug 1381084 is also uplifted.
MozReview-Commit-ID: 21YZObeSUa3
--HG--
extra : rebase_source : 8d543fe69f4ac9df5ccdc42d3ce47bb37eea4396
The MLGDeviceD3D11, CompositorD3D11 and TextureClient use the same synchronization mechanism.
Create the new SyncObjectClient/Host types for reusing code.
Add SyncObject.cpp/h and create two new data types: SyncObjectClient and SyncObjectHost.
The SyncObjectClient is used for the TextureClient synchronization at client side.
The SyncObjectHost is used for the TextureHost synchronization in renderers such
as MLGDeviceD3D11 and CompositorD3D11.
MozReview-Commit-ID: 3l56WK1aZ15
This patch move common canvas interfaces out of layer. So I create a
base class CanvasRenderer which move interfaces from CanvasLayer.
CopyableCanvasRenderer from CopyableCanvasLayer, ClientCanvasRenderer
from ClientCanvasLayer and WebRenderCanvasRenderer from
WebRenderCanvasLayer. And finally, WebRenderCanvasRendererSync for the
non layers free mode and WebRenderCanvasRendererAsync for the layers
free mode.
Summary all changes in this patch.
* Move class CanvasLayer::Data to CanvasRenderer.h and rename it to
CanvasInitializeData. Because this class not only use by layer but also
* Move BasicCanvasLayer::UpdateSurface to
CopyableCanvasRenderer::ReadbackSurface.
* CanvasClient::Update now accepts ShareableCanvasRenderer as parameter.
not CanvasLayer.
use by layers-free mode. Move it out of layer's class makes more sense.
* Add InitializeCanvasRenderer in the canvas related classes to
initialize CanvasRenderer without involved layer.
* All canvas layer has function "CreateCanvasRendererInternal" that
initialize corresponding CanvasRenderer.
* Description of all CanvasRenderer classes:
** CanvasRenderer: Based classes.
** CopyableCanvasRenderer: Can readback canvas content to a
SourceSurface. Use by BasicCanvasLayer.
** ShareableCanvasRenderer: Provide IPC capabilities that allow sending
canvas content over IPC. This is pure virtual class because the IPC handling is
different in different LayerManager.
** ClientCanvasRenderer: Implement IPC handling for ClientLayerManager.
Use by ClientCanvasLayer.
** WebRenderCanvasRenderer: Implement IPC handling for
WebRenderLayerManager.
** WebRenderCanvasRendererSync: Use by WebRenderCanvasLayer.
** WebRenderCanvasRendererAsync: Use by layers-free mode in WebRender.
class diagram shows below:
+--------------+
|CanvasRenderer|
+-------+------+
^
|
+----------------------+
|CopyableCanvasRenderer|
+----------------------+
^
|
+-----------+-----------+
|ShareableCanvasRenderer|
+-----+-----------------+
^ ^
+-------------+ +-------+
| |
+--------------------+ +---------+-------------+
|ClientCanvasRenderer| |WebRenderCanvasRenderer|
+--------------------+ +--------+--+-----------+
^ ^
+-----------------------+ +----+
| |
+-------------+-------------+ +-------------+--------------+
|WebRenderCanvasRendererSync| |WebRenderCanvasRendererAsync|
+---------------------------+ +----------------------------+
MozReview-Commit-ID: 5hqQ19W169r
Doug Thayer
Ryan Hunt
sotaro
Narcis Beleuzu
Csoregi Natalia
Emilio Cobos Álvarez
Markus Stange
Noemi Erli
Martin Stransky
Kartikaya Gupta
Sebastian Hengst
Tristan Bourvon
Bas Schouten
Ryan VanderMeulen
Cosmin Sabou
Matt Woodrow
Milan Sreckovic
Ciure Andrei
Andrew Osmond
JerryShih
Hiroyuki Ikezoe
Chris Peterson
Dorel Luca
Andreea Pavel
Alexis Beingessner
Andrew McCreight
Jean-Yves Avenard
Jamie Nicol
Kevin Chen
David Anderson
Ting-Yu Lin
Daniel Holbert
Kris Maglione
Nicholas Nethercote
Kearwood "Kip" Gilbert
Mason Chang
Jeff Gilbert
Wes Kocher
Sylvestre Ledru
Morris Tseng
Phil Ringnalda