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
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
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.
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
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
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
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
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
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
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
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
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
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 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 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
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
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
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.
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.
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
