This patch adds two new prefs, gfx.webrender.scissored-cache-clears
.enabled and .force-enabled to control its status beyond the blocklist.
The former is true by default and allows one to turn the feature off by
flipping it to false. The latter allows one to force the feature on even
if the blocklist disables it. It also adds the status to the decision
log in about:support.
Differential Revision: https://phabricator.services.mozilla.com/D170507
Bug 1638709 describes artifacts when the webrender compositor is enabled
on certain Windows systems with NVIDIA cards and mixed monitor refresh
rates. As of bug 1704954, we currently disable DirectComposition on such
systems in Beta and Release as a mitigation.
Unfortunately, on a significant (albeit not yet fully characterized)
fraction of Windows 11 machines, the fallback compositor also has
issues, resulting in bug 1763981 (clipping of web content on first
entering fullscreen). Users experiencing this latter issue have hitherto
_not_ reported the former when testing on Nightly, suggesting that the
mitigation may be getting applied overbroadly.
Add a pref to allow disabling the mitigation in question, so that users
experiencing bug 1763981, but who are not subject to 1638709, have a
less intrusive workaround than remembering to hit F11 twice every time
they start Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D169389
Bug 1638709 describes artifacts when the webrender compositor is enabled
on certain Windows systems with NVIDIA cards and mixed monitor refresh
rates. As of bug 1704954, we currently disable DirectComposition on such
systems in Beta and Release as a mitigation.
Unfortunately, on a significant (albeit not yet fully characterized)
fraction of Windows 11 machines, the fallback compositor also has
issues, resulting in bug 1763981 (clipping of web content on first
entering fullscreen). Users experiencing this latter issue have hitherto
_not_ reported the former when testing on Nightly, suggesting that the
mitigation may be getting applied overbroadly.
Add a pref to allow disabling the mitigation in question, so that users
experiencing bug 1763981, but who are not subject to 1638709, have a
less intrusive workaround than remembering to hit F11 twice every time
they start Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D169389
Modify AHardwareBuffer implementation as to support gl::SharedSurface of out-of-process WebGL. And remove unused AHardwareBuffer implementation.
By limiting AHardwareBuffer only in GPU process, AHardwareBuffer implementation becomes simpler. We do not need to handle cross process AHardwareBuffer delivery and cross process android Fence delivery.
Differential Revision: https://phabricator.services.mozilla.com/D167911
The remote texture is processed asynchronously, but the WebGL rendering results are rendered synchronously with WebRender transaction by WebRender.
Async remote texture support is enabled only when CanvasRenderThread is used. This is to simplify implementation.
In async mode, remote texture of current RemoteTextureId might not be created yet when WebRenderImageHost::UseRemoteTexture() is called. In this case, RemoteTextureHostWrapper uses its own external image ID, otherwise the RemoteTextureHostWrapper uses compatible old remote texture for creating wr display list. RenderTextureHostWrapper calls RemoteTextureMap::GetExternalImageIdOfRemoteTextureSync() before is ussage. The GetExternalImageIdOfRemoteTextureSync() synchronously waits until remote texture becomes ready. The wait works since WebGL IPC handling is always done in CanvasRenderThread in async mode.
PWebGLChild::SendGetFrontBuffer() triggers sync IPC. It is called to ensure the compatible remote texture in RemoteTextureMap during RemoteTextureMap::GetRemoteTextureForDisplayList() call.
Differential Revision: https://phabricator.services.mozilla.com/D162971
The remote texture is processed asynchronously, but the WebGL rendering results are rendered synchronously with WebRender transaction by WebRender.
Async remote texture support is enabled only when CanvasRenderThread is used. This is to simplify implementation.
In async mode, remote texture of current RemoteTextureId might not be created yet when WebRenderImageHost::UseRemoteTexture() is called. In this case, RemoteTextureHostWrapper uses its own external image ID, otherwise the RemoteTextureHostWrapper uses compatible old remote texture for creating wr display list. RenderTextureHostWrapper calls RemoteTextureMap::GetExternalImageIdOfRemoteTextureSync() before is ussage. The GetExternalImageIdOfRemoteTextureSync() synchronously waits until remote texture becomes ready. The wait works since WebGL IPC handling is always done in CanvasRenderThread in async mode.
PWebGLChild::SendGetFrontBuffer() triggers sync IPC. It is called to ensure the compatible remote texture in RemoteTextureMap during RemoteTextureMap::GetRemoteTextureForDisplayList() call.
Differential Revision: https://phabricator.services.mozilla.com/D162971
We used to provide links to the bug numbers but this was broken
somewhere along the way. Now it is provided the failure IDs from which
it can attempt to extract a bug number, as well as always display any
failure ID and message whenever possible.
Differential Revision: https://phabricator.services.mozilla.com/D162734
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
Backdrop filter crashes newer Intel drivers on Windows. This patch adds
support to the blocklist infrastructure for backdrop filter, and hooks
this up with the CSS property table.
Differential Revision: https://phabricator.services.mozilla.com/D154950
Backdrop filter crashes newer Intel drivers on Windows. This patch adds
support to the blocklist infrastructure for backdrop filter, and hooks
this up with the CSS property table.
Differential Revision: https://phabricator.services.mozilla.com/D154950
If dedicated thread for out-of-process WebGL exists, compositor thread tasks are not delayed by WebGL tasks.
And Bug 1712486 requests that WebGL run on non-compositor thread.
Differential Revision: https://phabricator.services.mozilla.com/D151210
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
Reuse decoder device also to release on intel GPU on Windows, since it is also necessary for zero copy hardware decoded video.
Reuse decoder device handling is also updated as aligned to FEATURE_HW_DECODED_VIDEO_ZERO_COPY.
Differential Revision: https://phabricator.services.mozilla.com/D150448
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
With CI's NVIDIA GPU, SharedHandle of ID3D11Texture2D of hardware decoded video during no video copy caused rendering problem. When SharedHandle is not used, the rendering problem did not happen. But when video is rendered to WebGL texture, SharedHandle need to be used.
In this case, D3D11TextureIMFSampleImage copies original ID3D11Texture2D to a new ID3D11Texture2D and use a shared handled of the copied texture. And no video copy of future video frames are disabled.
NoCopyNV12Texture is renamed to ZeroCopyNV12Texture to clarify its meaning.
Differential Revision: https://phabricator.services.mozilla.com/D144598
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
This patch adds several new prefs to control what happens with
OffscreenCanvas. gfx.offscreencanvas.enabled works as it did before.
- gfx.offscreencanvas.domain-enabled: Enables OffscreenCanvas for
domains on the allowlist.
- gfx.offscreencanvas.domain-allowlist: Comma separated allowlist
which controls which domains can access the OffscreenCanvas constructor
and HTMLCanvasElement.transferControlToOffscreen.
- dom.workers.requestAnimation: Controls whether or not
request/cancelAnimationFrame are accessible from dedicated workers.
Ideally this would have used the same decision process as
OffscreenCanvas but there were unrelated build/runtime issues around
using a Func directive with DedicatedWorkerGlobalScope.
Differential Revision: https://phabricator.services.mozilla.com/D135928
If GL is threadsafe, we can run on the compositor thread. This appears
to have performance benefits, possibly because the renderer thread is
too busy. If GL is not threadsafe, we must run the WebGL OOP instances
on the renderer thread.
At the time of writing, only the nouveau drivers on Linux are considered
to be not threadsafe, so most users will see WebGL running on the
compositor thread. This patch also adds prefers to override the
blocklist to either assume GL is threadsafe
(webgl.threadsafe-gl.force-enabled) and not threadsafe
(webgl.threadsafe-gl.force-disabled).
Differential Revision: https://phabricator.services.mozilla.com/D130634
The default size on most platforms is 256*256 which corresponds to the default blob tile size. I didn't check on android so I set it to 512*512 above which we never batch the upload so that the behavior is unchanged, but I suspect that a smaller threshold like 256*256 would also work better there.
On Windows with heavy blob image workloads, not batching gives a 20%-30% improvement to the time spent in update_texture_cache.
Differential Revision: https://phabricator.services.mozilla.com/D129516