For use within accelerated Canvas2D, it is expedient to have a variant of Present
that explicitly acknowledges that there is a copy from a supplied WebGL framebuffer
into the swap chain back buffer, as is usually the case when remoting, so that it
can be relied upon for format conversions or other concerns. This allows Present
to remain simple and assume rendering happened directly to the back buffer, without
need of a copy.
This backs out some of the earlier changes to Present in 1754130 in favor of
separating the new copy behavior into an explicit CopyToSwapChain interface,
which supports a format swizzle that is useful for converting between Canvas2D
and WebGL swap chain formats. The behavior of CopyToSwapChain, as noted,
assumes that there is a supplied WebGL framebuffer that must be copied to the
swap chain back buffer before any compositing should occur.
Differential Revision: https://phabricator.services.mozilla.com/D138954
* Accept that finding an explicit unpack for a given stride might fail.
* Directly use the logic from the GLES spec for unpacking stride calculations.
* Use structuredSrcSize member.
* Calc explicit unpack based on dstStride, not srcStride.
Differential Revision: https://phabricator.services.mozilla.com/D136052
Most of the support for presenting a WebGLFramebuffer to a swap chain existed as part of the
mechanism for opaque WebXR framebuffer support. However, such "opaque" framebuffer are meant
to be opaque in the sense that their attachments can't be inspected or changed, which does
not provide the requisite level of control for efficiently implementing Canvas2D snapshots.
To this end, the existing Present mechanism is slightly extended to allow presenting to the
swap chain already present in WebGLFramebuffer without the existence of a corresponding
MozFramebuffer.
This also fixes a bug in that AsWebgl() was no longer being utilized in CanvasRenderer, such
that a new mechanism that routed GetFrontBuffer() was needed to fix the code rot.
There are also some efforts to remove a couple redundant copies I noticed in profiles along
the way.
Differential Revision: https://phabricator.services.mozilla.com/D138119
Most of the support for presenting a WebGLFramebuffer to a swap chain existed as part of the
mechanism for opaque WebXR framebuffer support. However, such "opaque" framebuffer are meant
to be opaque in the sense that their attachments can't be inspected or changed, which does
not provide the requisite level of control for efficiently implementing Canvas2D snapshots.
To this end, the existing Present mechanism is slightly extended to allow presenting to the
swap chain already present in WebGLFramebuffer without the existence of a corresponding
MozFramebuffer.
This also fixes a bug in that AsWebgl() was no longer being utilized in CanvasRenderer, such
that a new mechanism that routed GetFrontBuffer() was needed to fix the code rot.
There are also some efforts to remove a couple redundant copies I noticed in profiles along
the way.
Differential Revision: https://phabricator.services.mozilla.com/D138119
Also:
* Add label for WebGLContext::Create.
* *Remove* label for WebGLContext::Draw*, since the labels for these are
showing up in draw-call-heavy profiles. (~1.5%)
* WebGLContext::UniformData continues to not have a label, since that
would likely add another 2-3% labelling overhead.
* Add missing !mHost check to RecvTexImage.
Differential Revision: https://phabricator.services.mozilla.com/D134883
The swizzling operations were showing up in talos profiles on Linux with
GLX and using OOP WebGL. If DMABuf has been disabled, similar performance
should be observed with EGL as well. This patch combines the necessary
copies, swizzling between RGBA and BGRA, and premultiplication operations
as much as possible for GetFrontBufferSnapshot.
It also has the advantage of unblocking the WebGL thread in the
compositor process sooner since it is a sync IPC call and moving that
work to the caller which would be blocked anyways.
Differential Revision: https://phabricator.services.mozilla.com/D130690
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
Workers require all runnables to implement nsIDiscardableRunnable. This
is because the worker may want to terminate after going out of scope,
and want to discard any pending events. It should be safe to simply drop
any WebGL related events since we are going to tear down the context /
actors as well.
Also ensure that we record dirty events even without an associated
HTMLCanvasElement so that the OffscreenCanvas is notified properly.
Differential Revision: https://phabricator.services.mozilla.com/D130783
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
Workers require all runnables to implement nsIDiscardableRunnable. This
is because the worker may want to terminate after going out of scope,
and want to discard any pending events. It should be safe to simply drop
any WebGL related events since we are going to tear down the context /
actors as well.
Also ensure that we record dirty events even without an associated
HTMLCanvasElement so that the OffscreenCanvas is notified properly.
Differential Revision: https://phabricator.services.mozilla.com/D130783
For WebGL canvases with preserveDrawingBuffer:false, frontbuffer
snapshotting was not working properly.
If the frontbuffer had no user-fb associated with it,
was inexplicably calling BindDefaultFBForRead, which binds
*webgl*'s default FB, not *gl*'s default FB 0.
This caused frontbuffer snappshotting to actually snapshot the (cleared)
backbuffer instead of the visible frontbuffer contents.
Differential Revision: https://phabricator.services.mozilla.com/D126024
Currently we return an error when creating a WebGL context in headless
mode, but our WebGL implementation renders to an offscreen context, so
in theory it could work normally in a headless browser, and in practice
it already does work on some OSes. This patch removes that check; the
attempt to use GL may fail, in which case we'll return an error to
content.
The main purpose of this patch is to run content processes with headless
mode set in an otherwise non-headless browser, but it should also be
useful for fully headless mode. Comments in bug NNNNNNN indicate that
this change should be sufficient for headless WebGL on Windows and MacOS,
although it may not have been extensively tested.
Linux is more complicated. The EGL/X11 backend manages its own
connection to the X server (indirectly via the EGL library); a later
patch in this series allows doing that in GLX mode as well. Our Wayland
support can't do this yet, but it should be possible.
This patch also modifies the Linux sandbox policy so that content
processes can connect to a local X server (via the file broker) even when
the parent process is in headless mode.
Differential Revision: https://phabricator.services.mozilla.com/D118721
Previously we called GetFrontBufferSize, alloc'd a buffer, and called
FrontBufferSnapshotInto to read into the buffer.
Now, call FrontBufferSnapshotInto({}) to get size, and then alloc and
pass pointer to newly alloc'd data into
FrontBufferSnapshotInto(Some(ptr)).
Using the same function for both means that logic can't diverge and
cause mismatch bugs.
Differential Revision: https://phabricator.services.mozilla.com/D113611
Previously we called GetFrontBufferSize, alloc'd a buffer, and called
FrontBufferSnapshotInto to read into the buffer.
Now, call FrontBufferSnapshotInto({}) to get size, and then alloc and
pass pointer to newly alloc'd data into
FrontBufferSnapshotInto(Some(ptr)).
Using the same function for both means that logic can't diverge and
cause mismatch bugs.
Differential Revision: https://phabricator.services.mozilla.com/D113611
GfxInfo generally wants to be main-thread, so WebGL (especially
out-of-process) runs into problems sometimes.
Also rename to UNUSED_FEATURE_WEBGL_MSAA, pending removal.
Differential Revision: https://phabricator.services.mozilla.com/D91208
GfxInfo generally wants to be main-thread, so WebGL (especially
out-of-process) runs into problems sometimes.
Also remove obsolete FEATURE_WEBGL_MSAA.
Differential Revision: https://phabricator.services.mozilla.com/D91208
GfxInfo generally wants to be main-thread, so WebGL (especially
out-of-process) runs into problems sometimes.
Also remove obsolete FEATURE_WEBGL_MSAA.
Differential Revision: https://phabricator.services.mozilla.com/D91208
