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
WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
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
With async present we can now rely on being able to do readbacks from WebGL
in the GPU process, rather than needing CopySnapshotTo to accelerate this in
the content process. Just remove CopySnapshotTo since it doesn't help anymore.
Differential Revision: https://phabricator.services.mozilla.com/D150721
The async front buffer posting is going to be enabled by another bug.
Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.
Differential Revision: https://phabricator.services.mozilla.com/D150197
The async front buffer posting is going to be enabled by another bug.
Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.
Differential Revision: https://phabricator.services.mozilla.com/D150197
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
This patch separates out new helper methods that are shared with the
OffscreenCanvas display integration in a later part in this series.
It also standardizes on SupportsWeakPtr/WeakPtr instead of mixing in C++
standard library versions.
Differential Revision: https://phabricator.services.mozilla.com/D130782
This patch separates out new helper methods that are shared with the
OffscreenCanvas display integration in a later part in this series.
It also standardizes on SupportsWeakPtr/WeakPtr instead of mixing in C++
standard library versions.
Differential Revision: https://phabricator.services.mozilla.com/D130782
This mainly provides DrawTargetWebgl, which implements the subset of the DrawTarget
API necessary for integration with CanvasRenderingContext2D. It translates them to
suitable commands for its internal ClientWebGLContext, which then manages remoting
WebGL requests to the parent/GPU process.
Currently two shaders are used for drawing Canvas2D primitives, but can be expanded
in the future. These are an image shader and a solid color shader.
The core of this implementation revolves around TexturePacker and TextureHandle,
which cope with the necessity of frequently uploading SourceSurfaces for use with
WebGL. TexturePacker implements a bin-packing algorithm for packing these uploads
into texture pages, which can either be SharedTextures if they are reasonably small,
or StandaloneTextures if they are too big to pack in a SharedTexture. Each upload
is assigned a TextureHandle which is used to manage it in a move-to-front cache,
so that we can easily eject TextureHandles from the back of the cache if we have
too many. These TextureHandles are associated with the SourceSurface that spawned
them to more easily manage their lifetimes.
There are further dependent caches for dealing with blurred shadows and with text.
Shadows are cached in an uploaded texture bound to the SourceSurface that generated
them. Text is handled by caching entire runs in the GlyphCache (keyed by both their
rendering parameters and their glyphs). The text is first rasterized to a surface
and then uploaded to a texture in the GlyphCache which can be reused should the
text be encountered again.
To deal with commands we can't accelerate, a separate internal DrawTargetSkia is
also maintained. The content of the WebGL framebuffer is copied into it so that
drawing can then proceed in software from there. It remains in this fallover state
until the next frame, when it resets back to using the WebGL framebuffer again.
This acceleration is disabled by default. To enable it, you must toggle the pref
"gfx.canvas.accelerated" to true. This should be suitably different from the naming
of the previous SkiaGL prefs to not alias with them. There are a few dependent prefs
that follow from the previous SkiaGL prefs for setting the size limitations for
acceleration and also limitations for the internal texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D130388
This mainly provides DrawTargetWebgl, which implements the subset of the DrawTarget
API necessary for integration with CanvasRenderingContext2D. It translates them to
suitable commands for its internal ClientWebGLContext, which then manages remoting
WebGL requests to the parent/GPU process.
Currently two shaders are used for drawing Canvas2D primitives, but can be expanded
in the future. These are an image shader and a solid color shader.
The core of this implementation revolves around TexturePacker and TextureHandle,
which cope with the necessity of frequently uploading SourceSurfaces for use with
WebGL. TexturePacker implements a bin-packing algorithm for packing these uploads
into texture pages, which can either be SharedTextures if they are reasonably small,
or StandaloneTextures if they are too big to pack in a SharedTexture. Each upload
is assigned a TextureHandle which is used to manage it in a move-to-front cache,
so that we can easily eject TextureHandles from the back of the cache if we have
too many. These TextureHandles are associated with the SourceSurface that spawned
them to more easily manage their lifetimes.
There are further dependent caches for dealing with blurred shadows and with text.
Shadows are cached in an uploaded texture bound to the SourceSurface that generated
them. Text is handled by caching entire runs in the GlyphCache (keyed by both their
rendering parameters and their glyphs). The text is first rasterized to a surface
and then uploaded to a texture in the GlyphCache which can be reused should the
text be encountered again.
To deal with commands we can't accelerate, a separate internal DrawTargetSkia is
also maintained. The content of the WebGL framebuffer is copied into it so that
drawing can then proceed in software from there. It remains in this fallover state
until the next frame, when it resets back to using the WebGL framebuffer again.
This acceleration is disabled by default. To enable it, you must toggle the pref
"gfx.canvas.accelerated" to true. This should be suitably different from the naming
of the previous SkiaGL prefs to not alias with them. There are a few dependent prefs
that follow from the previous SkiaGL prefs for setting the size limitations for
acceleration and also limitations for the internal texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D130388
If we are re-forwarding a texture that has not been updated then it might still
be read locked. We rely on the read lock for us to know when the Compositor or
Renderer has finished with the texture. So this change copies it to a new
texture, which we can safely read lock.
If the texture is not read locked then we ensure that it is set as updated,
which means we will read lock it as we forward it.
Differential Revision: https://phabricator.services.mozilla.com/D119546
We needs to reduce file descriptor creation for AndroidHardwareBuffer to avoid out of file descriptor situation. SharedSurface_AndroidHardwareBuffer::ToSurfaceDescriptor() is called for every composition. It causes avoid out of file descriptor.
By the change, file descriptor is created only once for each AndroidHardwareBuffer of SharedSurface_AndroidHardwareBuffer.
Differential Revision: https://phabricator.services.mozilla.com/D90066
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
Part 1 - support RGB external surfaces for promotion to compositor
surfaces; add new shader permutations to handle all buffer kinds.
Set the promotion flag when the pixel format has no alpha, or when the
texture provider can guarantee all-solid alpha values.
Differential Revision: https://phabricator.services.mozilla.com/D71120
Part 1 - support RGB external surfaces for promotion to compositor
surfaces; add new shader permutations to handle all buffer kinds.
Set the promotion flag when the pixel format has no alpha, or when the
texture provider can guarantee all-solid alpha values.
Differential Revision: https://phabricator.services.mozilla.com/D71120
Splits WebGLContext into ClientWebGLContext and HostWebGLContext. The Client enables the JS-control of a WebGL context in a content procecss while the Host executes the WebGL graphics operations (via a WebGLContext that maintains much of the existing code) in the compositor process. At this point, the cross-process behavior is disabled -- this series of patches is an incremental step toward that final goal.
Differential Revision: https://phabricator.services.mozilla.com/D54018
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando