On Android, SurfaceTextures provide a transform matrix that should be
applied to texture coordinates when sampling from the texture. Prior
to bug 1731980 we ignored this value, and simply y-flipped the video
instead. On most devices the transform is just a y-flip, so this
produced the correct results. However, on some devices the transform
included a scale as well as the y-flip, meaning that we rendered
videos at an incorrect size.
The fix for bug 1731980 was to correctly apply the transformation.
However, it now appears that on Mediatek 6735 devices the transform
provided by the system is incorrect. On these devices, videos were
rendered correctly when we ignored the transform and just did a
y-flip, and now that we apply the transform videos are rendered at the
wrong size.
This patch makes it so that we override the system-provided transform
on these devices with a simple y-flip. The existing mIgnoreTransform
flag has been changed to an optional "transform override" value to
achieve this. We ensure that we only override the transform for
SurfaceTextures that are output from a MediaCodec, to ensure that we
don't accidentally apply the wrong transform to SurfaceTextures
attached to other sources.
Differential Revision: https://phabricator.services.mozilla.com/D155706
The UpdateImageKeys() did not detect TextureHost change from MacIOSurfaceTextureHostOGL to ShmemTextureHost with same format and size.
If we want to use TransactionBuilder::UpdateExternalImage(), TextureHost type needs to be same.
Differential Revision: https://phabricator.services.mozilla.com/D154495
On Android we use SurfaceTextures to render content from sources such
as the video decoder. These may have a transform set which is supposed
to be applied to the texture coordinates used to sample the
texture. Webrender (and software webrender), however, do not handle
this correctly, meaning videos may be rendered at the incorrect size
on some devices.
SurfaceTextures should always be rendered with their bottom-left being
their origin, eg vertically flipped. Additionally, the texture
transform returned on most devices seems to be a simple y-flip
transform with no scaling. Webrender currently just ignores the y-flip
due to the texture origin, which cancels out us not handling the
y-flip from the transform, meaning video looks correct on most
devices. Some devices, however, do return a scaling transform which we
must handle.
This patch removes the override of WebRenderTextureHost::NeedsYFlip()
that was causing us to ignore the y-flip due to the texture origin -
since we will now apply the transform we must handle this correctly
too.
It adds a virtual method RenderTextureHost::GetUvCoords(), that
returns the texture coordinates that should be used by webrender to
sample from external textures. In most cases these are simply (0, 0)
and (size.x, size.y), but in RenderAndroidSurfaceTextureHost we
override this function to apply the transformation. This ensures we
use the correct coordinates whenever the texture is rendered by
webrender, eg in both software and hardware webrender when rendering
in the non-compositing-path, and by hardware webrender's draw
compositor. Additionally, the composite.glsl shader requires a fix to
calculate the UV bounds correctly, as the coordinates may now be
inverted.
Lastly, we fix software webrender with the OpenGL
compositor. CompositorOGL already has the required functionality to
apply the texture transformation as it was used back in the layers
days. We must simply ensure that we pass the value of the
mIgnoreTransform flag from the original SurfaceTextureHost, through to
the RenderAndroidSurfaceTextureHost, and finally to the
SurfaceTextureSource which we hand to CompositorOGL.
Differential Revision: https://phabricator.services.mozilla.com/D144306
We need them for SVG primitives.
This patch adds a bit of plumbing to disable snapping some of the primitives and forcing the antialiasing shader feature where needed, and uses it for SVG solid rectangles and images.
Differential Revision: https://phabricator.services.mozilla.com/D139024
Instead of drawing updates into the correct spot in the destination
DataSourceSurface we just use it as scratch space and always
draw in the top-left with stride = bpp*width.
We add a dstOffset to the upload functions to support using
a subsurface.
Differential Revision: https://phabricator.services.mozilla.com/D116501
Whether or not we use a native texture or something else is affected by our
backend and the size of the texture. This patch adds a new function to
centralize that logic in TextureHost, and applies it in callsites that were
checking the backend to determine an image type.
Differential Revision: https://phabricator.services.mozilla.com/D106568
Whether or not we use a native texture or something else is affected by our
backend and the size of the texture. This patch adds a new function to
centralize that logic in TextureHost, and applies it in callsites that were
checking the backend to determine an image type.
Differential Revision: https://phabricator.services.mozilla.com/D106568
Whether or not we use a native texture or something else is affected by our
backend and the size of the texture. This patch adds a new function to
centralize that logic in TextureHost, and applies it in callsites that were
checking the backend to determine an image type.
Differential Revision: https://phabricator.services.mozilla.com/D106568
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
This interface is never used directly, and the only consumers of the virtual functions are by the derived classes themselves.
Differential Revision: https://phabricator.services.mozilla.com/D93180
When using the native RenderCompositor+SWGL on MacOS, we don't support passing buffer textures directly to the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D93179
For performance, it is better to use eglWaitSyncKHR() for andoid fence if possible.
This change is not used by gecko yet.
Differential Revision: https://phabricator.services.mozilla.com/D89882
When EGLSync is created from fence file descriptor, gecko should not close it. It should be closed by gecko only when EGLSync creation is failed.
Differential Revision: https://phabricator.services.mozilla.com/D91702
AHardwareBuffer requests to handle android fences. There are 2 type of fences, release fence and acquire fence. Some ideas were borrowed from b2g's FenceHandle implementation.
The release fence is a fence that is used for waiting until usage/composite of AHardwareBuffer is ended. It needs to be delivered from host side to client side. It is delivered via ImageBridge, since some TextureClientd str recycled without recycle callback.
The acquire fence is a fence that is used for waiting until rendering to its AHardwareBuffer is completed. It is delivered from client side to host side.
Differential Revision: https://phabricator.services.mozilla.com/D87298
AHardwareBuffer is supported since Android O(APIVersion 26). Implementation of AndroidHardwareBufferTextureData referred AndroidNativeWindowTextureData. Implementation of AndroidHardwareBufferTextureHost referred obsoleted GrallocTextureHost.
android fence is not supported yet.
Differential Revision: https://phabricator.services.mozilla.com/D81808
No functional change. AndroidSurfaceTexture related files are used on all platforms. They are needed only on Android.
Differential Revision: https://phabricator.services.mozilla.com/D80869
When NumSubTextures() returns 0, SurfaceTextureHost is not rendered to WebRebder by a check of AsyncImagePipelineManager::UpdateImageKeys().
Differential Revision: https://phabricator.services.mozilla.com/D66514
