MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
Calling RenderThread::Pause() without using low_priority_scene_sender could reduce the waiting time for Pause/Resume handling. RenderThread::PostEvent() already exists for positing task directly to RenderThread. And RenderCompositor::IsPaused() exists for handling RenderCompositor paused state.
Differential Revision: https://phabricator.services.mozilla.com/D224306
Instead of dropping the frame's memory chunk when a frame is replaced, place the chunks into a global pool. This mostly helps when running stress tests like motionmark's html suite that cause intense allocation spikes (around 90 chunks per frame).
We should revisit whether this is needed if the cost of deallocating large regions of memory in mozjemalloc improves in the future.
Differential Revision: https://phabricator.services.mozilla.com/D223924
The RemoteBackBuffer change is the only tricky thing. It comes from
bug 1616000, but since bug 1870512 we don't create child windows for
non-native notifications, so we can remove it.
The SizeMode plumbing is totally unused so remove it while at it.
Differential Revision: https://phabricator.services.mozilla.com/D209505
This patch corrects a few different issues related to recycling
MacIOSurface objects.
1) When recycling a surface, we must check that the cached surfaces
match all of the requested parameters, not just the size. If we do
not, we should just flush the whole cache immediately since they
should all be created with the same parameters.
2) Allocations can fail, and we should check for failing to get a
surface from the allocator and fall back if so.
3) Locking can fail, and we should check that return value at all of the
call sites.
This may help resolve a number of otherwise difficult to understand
crash signatures. It may also solve display corruption issues in rare
cases where the parameters that changed were roughly equivalent such
that everything appears to work, but they differ enough to change the
presentation.
Differential Revision: https://phabricator.services.mozilla.com/D222205
On Android, SurfaceTextures provide a transform that should be applied
to texture coordinates when sampling from the texture. Usually this is
simply a y-flip, but sometimes it includes a scale and slight
translation, eg when the video frame is contained within a larger
texture. Previously we ignored this transform but performed a y-flip,
meaning we rendered correctly most of the time, but not all of the
time.
Our first attempt to fix this was in bug 1731980. When rendering as a
compositor surface with RenderCompositorOGLSWGL, we supplied the
transform to CompositorOGL's shaders, which correctly fixed the bug
for this rendering path.
However, the attempted fix for hardware webrender in fact made things
worse. As UV coordinates are supplied to webrender unnormalized, then
the shaders normalize them by dividing by the actual texture size,
this effectively handled the scale component of the transform. (Though
not quite scaling by the correct amount, and ignoring the translation
component, sometimes resulting in a pixel-wide green seam being
visible at the video's edges.) When we additionally applied the
transformation to the coordinates, it resulted in the scale being
applied twice, and the video being rendered too far zoomed
in.
To make matters worse, when we received subsequent bug reports of
incorrect rendering on various devices we mistakenly assumed that the
devices must be buggy, rather than our code being incorrect. We
therefore reverted to ignoring the transform on these devices, thereby
breaking the software webrender path again.
Additionally, on devices without GL_OES_EGL_image_external_essl3
support, we must sample from the SurfaceTexture using an ESSL1
shader. This means we do not have access to the correct texture size,
meaning we cannot correctly normalize the UV coordinates. This results
in the video being rendered too far zoomed out. And in the
non-compositor-surface software webrender path, we were accidentally
downscaling the texture when reading back into a CPU buffer, resulting
in the video being rendered at the correct zoom, but being very
blurry.
This patch aims to handle the transform correctly, in all rendering
paths, hopefully once and for all.
For hardware webrender, we now supply the texture coordinates to
webrender already normalized, using the functionality added in the
previous patch. This avoids the shaders scaling the coordinates again,
or using an incorrect texture size to do so.
For RenderCompositorOGLSWGL, we continue to apply the transform using
CompositorOGL's shaders.
In the non-compositor-surface software webrender path, we make
GLReadPixelsHelper apply the transform when reading from the
SurfaceTexture in to the CPU buffer. Again using functionality added
earlier in this patch series. This avoids downscaling the image. We
can then provide the default untransformed and unnormalized UVs to
webrender. As a result we can now remove the virtual function
RenderTextureHost::GetUvCoords(), added in bug 1731980, as it no
longer serves any purpose: we no longer want to share the
implementation between RenderAndroidSurfaceTextureHost::Lock and
RenderTextureHostSWGL::LockSWGL.
Finally, we remove all transform overrides on the devices we
mistakenly assumed were buggy.
Differential Revision: https://phabricator.services.mozilla.com/D220582
Some external images must be sampled from by providing normalized UV
coordinates to webrender, but currently webrender only supports
unnormalized UVs.
This patch adds a flag to webrender's external image API that
specifies whether the UV coordinates supplied when the texture is
locked are normalized or unnormalized. This flag is plumbed through
webrender to the required locations. We then add support for taking
normalized UVs as inputs to the brush_image and cs_scale shaders. The
only other shader that can be used with external textures is the
composite shader, which already supports normalized UVs.
This does not change any behaviour, that will happen in the next patch
in this series.
Differential Revision: https://phabricator.services.mozilla.com/D220581
Add the capability to transform the texture coordinates when reading
from a texture, similar to existing support in GLBlitHelper and
CompositorOGL.
This patch doesn't change any behaviour, but this capability will be
made use of by a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D220580
On Android, SurfaceTextures provide a transform that should be applied
to texture coordinates when sampling from the texture. Usually this is
simply a y-flip, but sometimes it includes a scale and slight
translation, eg when the video frame is contained within a larger
texture. Previously we ignored this transform but performed a y-flip,
meaning we rendered correctly most of the time, but not all of the
time.
Our first attempt to fix this was in bug 1731980. When rendering as a
compositor surface with RenderCompositorOGLSWGL, we supplied the
transform to CompositorOGL's shaders, which correctly fixed the bug
for this rendering path.
However, the attempted fix for hardware webrender in fact made things
worse. As UV coordinates are supplied to webrender unnormalized, then
the shaders normalize them by dividing by the actual texture size,
this effectively handled the scale component of the transform. (Though
not quite scaling by the correct amount, and ignoring the translation
component, sometimes resulting in a pixel-wide green seam being
visible at the video's edges.) When we additionally applied the
transformation to the coordinates, it resulted in the scale being
applied twice, and the video being rendered too far zoomed
in.
To make matters worse, when we received subsequent bug reports of
incorrect rendering on various devices we mistakenly assumed that the
devices must be buggy, rather than our code being incorrect. We
therefore reverted to ignoring the transform on these devices, thereby
breaking the software webrender path again.
Additionally, on devices without GL_OES_EGL_image_external_essl3
support, we must sample from the SurfaceTexture using an ESSL1
shader. This means we do not have access to the correct texture size,
meaning we cannot correctly normalize the UV coordinates. This results
in the video being rendered too far zoomed out. And in the
non-compositor-surface software webrender path, we were accidentally
downscaling the texture when reading back into a CPU buffer, resulting
in the video being rendered at the correct zoom, but being very
blurry.
This patch aims to handle the transform correctly, in all rendering
paths, hopefully once and for all.
For hardware webrender, we now supply the texture coordinates to
webrender already normalized, using the functionality added in the
previous patch. This avoids the shaders scaling the coordinates again,
or using an incorrect texture size to do so.
For RenderCompositorOGLSWGL, we continue to apply the transform using
CompositorOGL's shaders.
In the non-compositor-surface software webrender path, we make
GLReadPixelsHelper apply the transform when reading from the
SurfaceTexture in to the CPU buffer. Again using functionality added
earlier in this patch series. This avoids downscaling the image. We
can then provide the default untransformed and unnormalized UVs to
webrender. As a result we can now remove the virtual function
RenderTextureHost::GetUvCoords(), added in bug 1731980, as it no
longer serves any purpose: we no longer want to share the
implementation between RenderAndroidSurfaceTextureHost::Lock and
RenderTextureHostSWGL::LockSWGL.
Finally, we remove all transform overrides on the devices we
mistakenly assumed were buggy.
Differential Revision: https://phabricator.services.mozilla.com/D220582
Some external images must be sampled from by providing normalized UV
coordinates to webrender, but currently webrender only supports
unnormalized UVs.
This patch adds a flag to webrender's external image API that
specifies whether the UV coordinates supplied when the texture is
locked are normalized or unnormalized. This flag is plumbed through
webrender to the required locations. We then add support for taking
normalized UVs as inputs to the brush_image and cs_scale shaders. The
only other shader that can be used with external textures is the
composite shader, which already supports normalized UVs.
This does not change any behaviour, that will happen in the next patch
in this series.
Differential Revision: https://phabricator.services.mozilla.com/D220581
Add the capability to transform the texture coordinates when reading
from a texture, similar to existing support in GLBlitHelper and
CompositorOGL.
This patch doesn't change any behaviour, but this capability will be
made use of by a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D220580
With current gecko, Super Resolution became inactive automatically when video overlay is removed. However, when the video overlay used Super Resolution and power change becomes false, it needs to call SetVpSuperResolution with aEnable=false for disabling Super Resolution.
Differential Revision: https://phabricator.services.mozilla.com/D219831
With NVIDIA GPU, original ID3D11Texture2D created by compositor device and ID3D11Texture2D opened from shared handle compositor device seemed to work differently. The original ID3D11Texture2D seemed to work well with STR of Bug 1911237 with NVIDIA GPU.
Then if ID3D11Texture2D is created by compositor device, it seems better to use GpuProcessTextureId instead of shared handle.
Differential Revision: https://phabricator.services.mozilla.com/D218903
The tile pool keeps a strong reference to all of its allocations and reuses them when their reference count gets down to one.
Jemalloc only uses thread-local arenas for small allocations (<496 bytes) so it does not matter what thread the blob tiles which are typically much larger, are deallocated in.
Differential Revision: https://phabricator.services.mozilla.com/D218547
The tile pool keeps a strong reference to all of its allocations and reuses them when their reference count gets down to one.
Jemalloc only uses thread-local arenas for small allocations (<496 bytes) so it does not matter what thread the blob tiles which are typically much larger, are deallocated in.
Differential Revision: https://phabricator.services.mozilla.com/D218547
The tile pool keeps a strong reference to all of its allocations and reuses them when their reference count gets down to one.
Jemalloc only uses thread-local arenas for small allocations (<496 bytes) so it does not matter what thread the blob tiles which are typically much larger, are deallocated in.
Differential Revision: https://phabricator.services.mozilla.com/D218547
YUV422P10 is needed to properly tag decoded YUV422P10 video. NV16 is
needed to describe the macOS 10-bit YUV422 formats.
Differential Revision: https://phabricator.services.mozilla.com/D217334
This is just a renaming patch, motivated by a need for clarity before
addding more YUV formats. Comments and log messages are updated as well,
and one function in MacIOSurface is renamed.
There is one small change in TextureHost.cpp to satisfy clang-tidy.
Differential Revision: https://phabricator.services.mozilla.com/D217883
Bug 1908585 fix forgot to call DisableVideoOverlay() in DCSurfaceVideo::PresentVideo() by mistake. It is necessary to disable video overlay when the overlay is slow.
Differential Revision: https://phabricator.services.mozilla.com/D218097
