2021-11-04 19:29:44 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
#ifndef _include_gfx_ipc_CanvasManagerChild_h__
|
|
|
|
#define _include_gfx_ipc_CanvasManagerChild_h__
|
|
|
|
|
Bug 1736177 - Part 9. Add plumbing to snapshot worker canvas contexts from the main thread. r=jgilbert,ipc-reviewers,nika
Right now, if we wanted to get a snapshot of an OffscreenCanvas context
on a worker thread from the main thread, we would need to block the main
thread on the worker thread, and from the worker thread, issue a sync
IPC call get the front buffer snapshot.
This patch adds an alternative which allows the main thread to go
directly to the canvas owning thread in the compositor process to get
the snapshot, thereby bypassing the worker thread in content process
entirely. All it needs as the unique ID of the CanvasManagerChild
instance, and the protocol ID of the WebGLChild instance.
This will be used for Firefox screenshots, New Tab tiles, and printing.
Differential Revision: https://phabricator.services.mozilla.com/D130785
2021-12-10 05:57:55 +03:00
|
|
|
#include "mozilla/Atomics.h"
|
2021-11-04 19:29:44 +03:00
|
|
|
#include "mozilla/gfx/PCanvasManagerChild.h"
|
2022-04-27 19:05:28 +03:00
|
|
|
#include "mozilla/gfx/Types.h"
|
2021-11-04 19:29:44 +03:00
|
|
|
#include "mozilla/ThreadLocal.h"
|
2023-12-20 16:01:19 +03:00
|
|
|
#include <set>
|
2021-11-04 19:29:44 +03:00
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace dom {
|
2023-12-20 16:01:19 +03:00
|
|
|
class CanvasRenderingContext2D;
|
|
|
|
class ThreadSafeWorkerRef;
|
2021-11-04 19:29:44 +03:00
|
|
|
class WorkerPrivate;
|
|
|
|
} // namespace dom
|
|
|
|
|
2023-09-25 19:18:36 +03:00
|
|
|
namespace layers {
|
|
|
|
class CanvasChild;
|
2023-12-20 16:01:19 +03:00
|
|
|
class ActiveResourceTracker;
|
2023-09-25 19:18:36 +03:00
|
|
|
} // namespace layers
|
|
|
|
|
2022-02-02 23:49:23 +03:00
|
|
|
namespace webgpu {
|
|
|
|
class WebGPUChild;
|
|
|
|
} // namespace webgpu
|
|
|
|
|
2021-11-04 19:29:44 +03:00
|
|
|
namespace gfx {
|
Bug 1736177 - Part 9. Add plumbing to snapshot worker canvas contexts from the main thread. r=jgilbert,ipc-reviewers,nika
Right now, if we wanted to get a snapshot of an OffscreenCanvas context
on a worker thread from the main thread, we would need to block the main
thread on the worker thread, and from the worker thread, issue a sync
IPC call get the front buffer snapshot.
This patch adds an alternative which allows the main thread to go
directly to the canvas owning thread in the compositor process to get
the snapshot, thereby bypassing the worker thread in content process
entirely. All it needs as the unique ID of the CanvasManagerChild
instance, and the protocol ID of the WebGLChild instance.
This will be used for Firefox screenshots, New Tab tiles, and printing.
Differential Revision: https://phabricator.services.mozilla.com/D130785
2021-12-10 05:57:55 +03:00
|
|
|
class DataSourceSurface;
|
2021-11-04 19:29:44 +03:00
|
|
|
|
|
|
|
class CanvasManagerChild final : public PCanvasManagerChild {
|
|
|
|
public:
|
|
|
|
NS_INLINE_DECL_THREADSAFE_REFCOUNTING(CanvasManagerChild, override);
|
|
|
|
|
Bug 1736177 - Part 9. Add plumbing to snapshot worker canvas contexts from the main thread. r=jgilbert,ipc-reviewers,nika
Right now, if we wanted to get a snapshot of an OffscreenCanvas context
on a worker thread from the main thread, we would need to block the main
thread on the worker thread, and from the worker thread, issue a sync
IPC call get the front buffer snapshot.
This patch adds an alternative which allows the main thread to go
directly to the canvas owning thread in the compositor process to get
the snapshot, thereby bypassing the worker thread in content process
entirely. All it needs as the unique ID of the CanvasManagerChild
instance, and the protocol ID of the WebGLChild instance.
This will be used for Firefox screenshots, New Tab tiles, and printing.
Differential Revision: https://phabricator.services.mozilla.com/D130785
2021-12-10 05:57:55 +03:00
|
|
|
explicit CanvasManagerChild(uint32_t aId);
|
|
|
|
uint32_t Id() const { return mId; }
|
2022-04-27 19:05:28 +03:00
|
|
|
already_AddRefed<DataSourceSurface> GetSnapshot(
|
|
|
|
uint32_t aManagerId, int32_t aProtocolId,
|
2022-12-23 23:41:02 +03:00
|
|
|
const Maybe<RemoteTextureOwnerId>& aOwnerId, SurfaceFormat aFormat,
|
2022-04-27 19:05:28 +03:00
|
|
|
bool aPremultiply, bool aYFlip);
|
2021-11-04 19:29:44 +03:00
|
|
|
void ActorDestroy(ActorDestroyReason aReason) override;
|
|
|
|
|
|
|
|
static CanvasManagerChild* Get();
|
2023-12-20 16:01:19 +03:00
|
|
|
static CanvasManagerChild* MaybeGet();
|
2021-11-04 19:29:44 +03:00
|
|
|
static void Shutdown();
|
|
|
|
static bool CreateParent(
|
|
|
|
mozilla::ipc::Endpoint<PCanvasManagerParent>&& aEndpoint);
|
|
|
|
|
2023-12-20 16:01:19 +03:00
|
|
|
void AddShutdownObserver(dom::CanvasRenderingContext2D* aCanvas);
|
|
|
|
void RemoveShutdownObserver(dom::CanvasRenderingContext2D* aCanvas);
|
|
|
|
|
2023-09-25 19:18:36 +03:00
|
|
|
bool IsCanvasActive() { return mActive; }
|
|
|
|
void EndCanvasTransaction();
|
2023-12-08 19:11:27 +03:00
|
|
|
void ClearCachedResources();
|
2023-09-25 19:18:36 +03:00
|
|
|
void DeactivateCanvas();
|
Bug 1829026 - Update CanvasTranslator to work with DrawTargetWebgl. r=aosmond
This adds the necessary infrastructure for CanvasTranslator to allocate DrawTargetWebgl
instead of just allocating TextureData, and to use RemoteTextureMap to handle sending
the DrawTargetWebgl frames to the compositor.
This optimizes snapshot transport to use fewer copies to and from shmems when we know
the snapshot contents can be sourced from a shmem.
This adds a blocking mechanism separate from deactivation so that existing DrawTargetWebgls
can continue processing events while denying further ones from being created in the event
that allocating further DrawTargetWebgls might cause problems, but so that we don't disrupt
canvases that are already in flight.
PersistentBufferProviderAccelerated still remains the buffer provider for the new setup,
but just allocates a single RecordedTextureData internally. Since DrawTargetWebgl already
does its own swap chain management internally, we do not want to use the multiple texture
client strategy that PersistentBufferProviderShared does.
This adds a fallback mechanism such that if DrawTargetWebgl allocation fails, a TextureData
is allocated instead that still sends results to RemoteTextureMap. This has the advantage
that we don't need to synchronously block in the content process to verify if acceleration
succeeded, as the costs of such blocking are rather extreme and we must still produce the
rendered frame to ensure the user sees the correct result if the speculative acceleration
failed. It then notifies the content process asynchronously via the refresh mechanism to
try to recreate a non-accelerated buffer provider when it is ready.
There is one additional hitch in RemoteTextureMap that we need to add a mechanism to deal
with the setup of the RemoteTextureOwner. When display list building initially needs to get
the remote texture, the RemoteTextureOwner might not exist yet. In this case, we need to add
a block to ensure we wait for that to occur so that we do not render an erroneous result.
Previously, this block was handled in ClientWebGLContext. Since that is no longer used,
the block must be reinstated somewhere else until a non-blocking mechanism for display list
building to proceed with a stub texture host wrapper can be implemented.
Currently this leaves the gfx.canvas.remote and gfx.canvas.accelerated prefs as separate
toggles rather than trying to lump everything into one mechanism. While this may be desirable
in the future, currently Direct2D remote canvas is a separate acceleration mechanism that
needs to co-exist with the WebGL acceleration, and so being able to toggle both on or off
for testing is desirable.
Differential Revision: https://phabricator.services.mozilla.com/D194352
2023-12-18 21:10:46 +03:00
|
|
|
void BlockCanvas();
|
2023-09-25 19:18:36 +03:00
|
|
|
|
|
|
|
RefPtr<layers::CanvasChild> GetCanvasChild();
|
|
|
|
|
2022-02-02 23:49:23 +03:00
|
|
|
RefPtr<webgpu::WebGPUChild> GetWebGPUChild();
|
|
|
|
|
2023-12-20 16:01:19 +03:00
|
|
|
layers::ActiveResourceTracker* GetActiveResourceTracker();
|
|
|
|
|
2021-11-04 19:29:44 +03:00
|
|
|
private:
|
|
|
|
~CanvasManagerChild();
|
2023-12-20 16:01:19 +03:00
|
|
|
void DestroyInternal();
|
2021-11-04 19:29:44 +03:00
|
|
|
void Destroy();
|
|
|
|
|
2023-12-20 16:01:19 +03:00
|
|
|
RefPtr<mozilla::dom::ThreadSafeWorkerRef> mWorkerRef;
|
2023-09-25 19:18:36 +03:00
|
|
|
RefPtr<layers::CanvasChild> mCanvasChild;
|
2022-02-02 23:49:23 +03:00
|
|
|
RefPtr<webgpu::WebGPUChild> mWebGPUChild;
|
2023-12-20 16:01:19 +03:00
|
|
|
UniquePtr<layers::ActiveResourceTracker> mActiveResourceTracker;
|
2023-12-20 16:01:19 +03:00
|
|
|
std::set<dom::CanvasRenderingContext2D*> mActiveCanvas;
|
Bug 1736177 - Part 9. Add plumbing to snapshot worker canvas contexts from the main thread. r=jgilbert,ipc-reviewers,nika
Right now, if we wanted to get a snapshot of an OffscreenCanvas context
on a worker thread from the main thread, we would need to block the main
thread on the worker thread, and from the worker thread, issue a sync
IPC call get the front buffer snapshot.
This patch adds an alternative which allows the main thread to go
directly to the canvas owning thread in the compositor process to get
the snapshot, thereby bypassing the worker thread in content process
entirely. All it needs as the unique ID of the CanvasManagerChild
instance, and the protocol ID of the WebGLChild instance.
This will be used for Firefox screenshots, New Tab tiles, and printing.
Differential Revision: https://phabricator.services.mozilla.com/D130785
2021-12-10 05:57:55 +03:00
|
|
|
const uint32_t mId;
|
2023-09-25 19:18:36 +03:00
|
|
|
bool mActive = true;
|
Bug 1829026 - Update CanvasTranslator to work with DrawTargetWebgl. r=aosmond
This adds the necessary infrastructure for CanvasTranslator to allocate DrawTargetWebgl
instead of just allocating TextureData, and to use RemoteTextureMap to handle sending
the DrawTargetWebgl frames to the compositor.
This optimizes snapshot transport to use fewer copies to and from shmems when we know
the snapshot contents can be sourced from a shmem.
This adds a blocking mechanism separate from deactivation so that existing DrawTargetWebgls
can continue processing events while denying further ones from being created in the event
that allocating further DrawTargetWebgls might cause problems, but so that we don't disrupt
canvases that are already in flight.
PersistentBufferProviderAccelerated still remains the buffer provider for the new setup,
but just allocates a single RecordedTextureData internally. Since DrawTargetWebgl already
does its own swap chain management internally, we do not want to use the multiple texture
client strategy that PersistentBufferProviderShared does.
This adds a fallback mechanism such that if DrawTargetWebgl allocation fails, a TextureData
is allocated instead that still sends results to RemoteTextureMap. This has the advantage
that we don't need to synchronously block in the content process to verify if acceleration
succeeded, as the costs of such blocking are rather extreme and we must still produce the
rendered frame to ensure the user sees the correct result if the speculative acceleration
failed. It then notifies the content process asynchronously via the refresh mechanism to
try to recreate a non-accelerated buffer provider when it is ready.
There is one additional hitch in RemoteTextureMap that we need to add a mechanism to deal
with the setup of the RemoteTextureOwner. When display list building initially needs to get
the remote texture, the RemoteTextureOwner might not exist yet. In this case, we need to add
a block to ensure we wait for that to occur so that we do not render an erroneous result.
Previously, this block was handled in ClientWebGLContext. Since that is no longer used,
the block must be reinstated somewhere else until a non-blocking mechanism for display list
building to proceed with a stub texture host wrapper can be implemented.
Currently this leaves the gfx.canvas.remote and gfx.canvas.accelerated prefs as separate
toggles rather than trying to lump everything into one mechanism. While this may be desirable
in the future, currently Direct2D remote canvas is a separate acceleration mechanism that
needs to co-exist with the WebGL acceleration, and so being able to toggle both on or off
for testing is desirable.
Differential Revision: https://phabricator.services.mozilla.com/D194352
2023-12-18 21:10:46 +03:00
|
|
|
bool mBlocked = false;
|
2021-11-04 19:29:44 +03:00
|
|
|
|
|
|
|
static MOZ_THREAD_LOCAL(CanvasManagerChild*) sLocalManager;
|
Bug 1736177 - Part 9. Add plumbing to snapshot worker canvas contexts from the main thread. r=jgilbert,ipc-reviewers,nika
Right now, if we wanted to get a snapshot of an OffscreenCanvas context
on a worker thread from the main thread, we would need to block the main
thread on the worker thread, and from the worker thread, issue a sync
IPC call get the front buffer snapshot.
This patch adds an alternative which allows the main thread to go
directly to the canvas owning thread in the compositor process to get
the snapshot, thereby bypassing the worker thread in content process
entirely. All it needs as the unique ID of the CanvasManagerChild
instance, and the protocol ID of the WebGLChild instance.
This will be used for Firefox screenshots, New Tab tiles, and printing.
Differential Revision: https://phabricator.services.mozilla.com/D130785
2021-12-10 05:57:55 +03:00
|
|
|
static Atomic<uint32_t> sNextId;
|
2021-11-04 19:29:44 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace gfx
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif // _include_gfx_ipc_CanvasManagerChild_h__
|