clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/layers/composite/ContainerLayerComposite.cpp:132:6 [-Wmissing-prototypes] no previous prototype for function 'TransformLayerGeometry'
gfx/layers/composite/LayerManagerComposite.cpp:1409:6 [-Wmissing-prototypes] no previous prototype for function 'ComputeVisibleRegionForChildren'
gfx/layers/composite/LayerManagerComposite.cpp:234:6 [-Wmissing-prototypes] no previous prototype for function 'ShouldProcessLayer'
gfx/layers/composite/TiledContentHost.cpp:156:6 [-Wmissing-prototypes] no previous prototype for function 'UseTileTexture'
gfx/layers/ipc/CompositorBridgeParent.cpp:1827:6 [-Wmissing-prototypes] no previous prototype for function 'EraseLayerState'
gfx/layers/ipc/CompositorBridgeParent.cpp:2140:6 [-Wmissing-prototypes] no previous prototype for function 'UpdateIndirectTree'
gfx/layers/opengl/OGLShaderProgram.cpp:28:6 [-Wmissing-prototypes] no previous prototype for function 'AddUniforms'
Differential Revision: https://phabricator.services.mozilla.com/D20265
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
BufferContentType and BufferSizeOkFor make more sense as general functions for
any RotatedBuffer, and this helps out in a later patch.
MozReview-Commit-ID: EAVodvl4WTu
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
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
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
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
