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
If we want to re-enable SanityTest.jsm test, we need to disable native compositor(DirectComposition) on the testing window, since taking snapshot of native compositor is very slow on Windows. Then CompositorOptions could be used to notice to disable native compositor(DirectComposition).
To notice it from SanityTest.jsm to gecko, nsIAppWindow::needFastSnaphot() is used.
Differential Revision: https://phabricator.services.mozilla.com/D130824
DCSurfaceVideo::mSwapChainSurfaceHandle is not initialized. It causes invalid handle close in DCSurfaceVideo::ReleaseDecodeSwapChainResources().
Differential Revision: https://phabricator.services.mozilla.com/D143966
This decodes 10-bit AV1 into the P010 surface format. Because of the
needed bit shifting to move the 10-bits to the MSB positions, it can't use
a straight memcpy for the Y values.
Differential Revision: https://phabricator.services.mozilla.com/D143436
The renderer thread is at the end of the rendering pipeline. For smoothness it is important that it completes its work quickly as soon as it receives some. It does not produce work for other threads so we don't risk of causing some build up. On the other hand, the higher priority will help with with avoiding some cases of congestion of work coming from the content process.
This only bumps the priority of the renderer thread as opposed to the entire GPU process (Blink does the latter). This is because we currently have too many thread on the GPU process so there is a risk of completely starving other processes. It's still something we want to consider and might be safer after we have done the work of reducing the number of threads.
Differential Revision: https://phabricator.services.mozilla.com/D143056
The shared font namespace was getting allocated by the RenderBackend, while
we otherwise allocated namespaces for documents on the client. We need to make
sure that if namespace allocation happens on the client, that it also happens
on the client for the shared font namespace. This adds to RendererOptions to
make passing in a shared font namespace allocated by the client possible.
Differential Revision: https://phabricator.services.mozilla.com/D142381
DCSurfaceVideo::PresentVideo() needs to be called only when RenderTextureHost, swapChainSize or VideoSwapChain are updated.
Since bug 1667303 fix, DCSurfaceVideo::PresentVideo() is called even when it is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D142315
This replaces the sharing of SharedFontInstanceMap with a new structure
SharedFontResources that can be used to trade a mechanism between threads
of a single Renderer instance for de-duplicating fonts and font instances.
SharedFontResources stores maps of FontTemplates and FontInstances as well
as a new FontKeyMap and FontInstanceKeyMap which handles the mapping of
namespace-local font keys to a shared key. The shared key then maps to
the real, de-duplicated resource (template or instance) which has a lifetime
beyond that of any individual namespace that may refer to it. Reference
counting is used to track the lifetime of the shared key so that when no key
map entries refer to the shared key any longer, it will then expire and
be cleaned up. This does cause some complications with clearing a namespace
in that rather than simply crawling through a table looking for resources
with a given IdNamespace, we have to check for shared keys that have expired
when clearing a namespace caused the last references to their mappings
to be removed.
Given that ApiResources handles the up-front addition of font templates
and instances, while ResourceCache within the RenderBackend handles deletion,
most of these mappings have to be shared between threads, which is why they
live within SharedFontResources. When resource updates are processed by
either ApiResources or ResourceCache, we create a shared key as necessary to
add the font resource, and then delete the shared font resource when a resource
update caused the last reference to the resource's shared key to expire.
This only tries to de-duplicate fonts within a single Renderer (window). Since
each Renderer has its own texture cache and dependent glyph cache, sharing
across multiple windows would require extra complication with storing font
bitmaps outside of the texture cache and outside the Renderer instance itself.
For the sake of simplicity and to better understand how de-duplication impacts
performance, this patch only tries to address sharing within a single window.
Differential Revision: https://phabricator.services.mozilla.com/D140561
SimulateDeviceReset() works differently from actual device reset handling. It seems better to make SimulateDeviceReset() more similar to actual device reset handling.
Differential Revision: https://phabricator.services.mozilla.com/D140161
P010 is trivially the same as NV12, but the 10-bit colors are packed into
the most significant bits instead of the least significant bits. This changes
the yuv shader to use the correct packing for P010. It treats P010 as its
own yuv format, which requires a lot of scaffolding.
Differential Revision: https://phabricator.services.mozilla.com/D140422
This is a preparation of Bug 1723207.
D3D11TextureIMFSampleImage is used for storing ID3D11Texture2D of IMFSample. Array index handling is added, since there are cases that hardware decoder uses array texture. D3D11TextureIMFSampleImage is expected to be used in GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D140017
This cuts the time spent doing get_ct_font on macOS in half because of
various contention issues. It should also reduce overall memory usage
for large fonts because we have half as many threads loading the
fonts.
Differential Revision: https://phabricator.services.mozilla.com/D139946
I had assumed in bug 1750858 that we would only need to modify RenderBufferTextureHost.
It turns out macOS will also still use the ffmpeg decoder and so RenderExternalTextureHost
must report cropped YCbCr sizes as well.
Differential Revision: https://phabricator.services.mozilla.com/D139679
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
This makes WR properly handle mPicSize when RenderBufferTextureHost is used.
The main change is that we need to take care to pass in display().Size() from
the descriptor, and then further use that to carefully limit the size of the
CbCr texture, as it doesn't necessarily maintain an appropriate half-sized
scale with respect to the Y texture if it is padded.
Given that mPicSize should now actually work, we should no longer need any
of the previous mCroppedSize mechanisms that were added to work around this,
and so they are removed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D139267
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
This change mitigates the gap between the external_scroll_offset informed from
the main-thread and scroll_offset informed from APZ.
Some wrench reftests for this change are in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D133444
This was originally implemented in D111662 to work around a crash
that otherwise would get triggered in Gnome/Mutter.
The fix for that crash has been available for a couple of month now,
thus remove the workaround again.
This may help preventing flickering for menus in certain situations.
Differential Revision: https://phabricator.services.mozilla.com/D137251
Mike Hommey
Dan Robertson
Jamie Nicol
ganguin
sotaro
criss
Brad Werth
Nika Layzell
Iulian Moraru
Nicolas Silva
Lee Salzman
Andrew Osmond
Randell Jesup
Noemi Erli
Butkovits Atila
Florian Quèze
Jeff Muizelaar
Emilio Cobos Álvarez
Andi-Bogdan Postelnicu
Hiroyuki Ikezoe
Robert Mader