Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-11-30 16:22:00 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
0a4c37bc06
gecko-dev/dom/canvas/SourceSurfaceWebgl.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

76 lines
2.4 KiB
C
Raw Normal View History

Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00: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 MOZILLA_GFX_SOURCESURFACEWEBGL_H_
#define MOZILLA_GFX_SOURCESURFACEWEBGL_H_
#include "mozilla/gfx/2D.h"
#include "mozilla/WeakPtr.h"
Bug 1754130 - Support presenting a WebGLFramebuffer to its own swap chain without opaque FB. r=aosmond,jgilbert 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
2022-02-11 19:49:56 +00:00
namespace mozilla::gfx {
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
class DrawTargetWebgl;
Bug 1829026 - Support using DrawTargetWebgl via remote canvas. r=aosmond This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext. Instead, it must directly interact with WebGLContext which requires some noisy changes of the GL rendering API used. In addition, this restructures SharedContextWebgl so that it can be explicitly allocated and further DrawTargetWebgls can be allocated that feed off of it. This is all towards the ultimate goal of relying on remote canvas infrastructure for remoting instead. Differential Revision: https://phabricator.services.mozilla.com/D194351
2023-12-18 18:10:46 +00:00
class SharedContextWebgl;
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
class TextureHandle;
// SourceSurfaceWebgl holds WebGL resources that can be used to efficiently
// copy snapshot data between multiple DrawTargetWebgls. It also takes care
// of copy-on-write behavior when the owner target is modified or destructs.
class SourceSurfaceWebgl : public DataSourceSurface {
public:
MOZ_DECLARE_REFCOUNTED_VIRTUAL_TYPENAME(SourceSurfaceWebgl, override)
Bug 1771007 - Avoid sending SourceSurfaceWebgl off-thread. r=jrmuizel,gfx-reviewers BorrowSnapshot can be called by OffScreenCanvas in various places that may send a SourceSurfaceWebgl to the main thread. If it did not originate from the main thread, then this can cause multiple threads to use it. In general we want to avoid this. For now, override BorrowSnapshot and make it always force a Skia snapshot that can be safely shared between threads instead of SourceSurfaceWebgl. Differential Revision: https://phabricator.services.mozilla.com/D152417
2022-07-26 01:28:48 +00:00
explicit SourceSurfaceWebgl(DrawTargetWebgl* aDT);
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
virtual ~SourceSurfaceWebgl();
SurfaceType GetType() const override { return SurfaceType::WEBGL; }
IntSize GetSize() const override { return mSize; }
SurfaceFormat GetFormat() const override { return mFormat; }
uint8_t* GetData() override;
int32_t Stride() override;
bool Map(MapType aType, MappedSurface* aMappedSurface) override;
void Unmap() override;
Bug 1754130 - Support presenting a WebGLFramebuffer to its own swap chain without opaque FB. r=aosmond,jgilbert 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
2022-02-11 19:49:56 +00:00
bool HasReadData() const { return !!mData; }
Bug 1752841 - Add ExtractSubrect API to SourceSurface. r=jrmuizel CanvasRenderingContext2D relies upon CreateSimilarDrawTarget to create extract a subrect from a surface to draw. However, DrawTargetWebgl does not return an accelerated DT for that API as creating an entirely new context can be quite expensive. To work around this, this adds a specific ExtractSubrect API for SourceSurface that can bypass the entire need to create a temporary DrawTarget to copy into. Differential Revision: https://phabricator.services.mozilla.com/D164118
2022-12-07 21:06:32 +00:00
already_AddRefed<SourceSurface> ExtractSubrect(const IntRect& aRect) override;
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
private:
friend class DrawTargetWebgl;
Bug 1829026 - Support using DrawTargetWebgl via remote canvas. r=aosmond This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext. Instead, it must directly interact with WebGLContext which requires some noisy changes of the GL rendering API used. In addition, this restructures SharedContextWebgl so that it can be explicitly allocated and further DrawTargetWebgls can be allocated that feed off of it. This is all towards the ultimate goal of relying on remote canvas infrastructure for remoting instead. Differential Revision: https://phabricator.services.mozilla.com/D194351
2023-12-18 18:10:46 +00:00
friend class SharedContextWebgl;
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
Bug 1876536 - Part 1: Remove self refcounts within constructor in dom/canvas r=gfx-reviewers,lsalzman Differential Revision: https://phabricator.services.mozilla.com/D199626
2024-02-01 11:03:59 +00:00
explicit SourceSurfaceWebgl(const RefPtr<SharedContextWebgl>& aSharedContext);
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
bool EnsureData();
Bug 1771504 - Handle mapped DrawTargetWebgl snapshots that subsequently need to be drawn. r=aosmond,gfx-reviewers If a DrawTargetWebgl's snapshot is mapped, then subsequently drawn, this can cause an assert to trigger as we may not have a handle available when we go to unlink the cached snapshot that later gets added to the texture cache. This assert is otherwise harmless, so we just fix the assert. Otherwise, there are some inefficiencies with this scenario that this patch also tries to address. When we go to draw the snapshot, DrawTargetWillChange gets invoked on the snapshot, and we can ensure in this case the handle is copied efficiently here rather than later uploaded from mapped data. Differential Revision: https://phabricator.services.mozilla.com/D148102
2022-06-02 15:27:00 +00:00
void DrawTargetWillChange(bool aNeedHandle);
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
void GiveTexture(RefPtr<TextureHandle> aHandle);
Bug 1876536 - Part 1: Remove self refcounts within constructor in dom/canvas r=gfx-reviewers,lsalzman Differential Revision: https://phabricator.services.mozilla.com/D199626
2024-02-01 11:03:59 +00:00
void SetHandle(TextureHandle* aHandle);
Bug 1829026 - Support using DrawTargetWebgl via remote canvas. r=aosmond This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext. Instead, it must directly interact with WebGLContext which requires some noisy changes of the GL rendering API used. In addition, this restructures SharedContextWebgl so that it can be explicitly allocated and further DrawTargetWebgls can be allocated that feed off of it. This is all towards the ultimate goal of relying on remote canvas infrastructure for remoting instead. Differential Revision: https://phabricator.services.mozilla.com/D194351
2023-12-18 18:10:46 +00:00
void OnUnlinkTexture(SharedContextWebgl* aContext);
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
DrawTargetWebgl* GetTarget() const { return mDT.get(); }
SurfaceFormat mFormat = SurfaceFormat::UNKNOWN;
IntSize mSize;
// Any data that has been read back from the WebGL context for mapping.
RefPtr<DataSourceSurface> mData;
// The draw target that currently owns the texture for this surface.
WeakPtr<DrawTargetWebgl> mDT;
// The actual shared context that any WebGL resources belong to.
Bug 1829026 - Support using DrawTargetWebgl via remote canvas. r=aosmond This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext. Instead, it must directly interact with WebGLContext which requires some noisy changes of the GL rendering API used. In addition, this restructures SharedContextWebgl so that it can be explicitly allocated and further DrawTargetWebgls can be allocated that feed off of it. This is all towards the ultimate goal of relying on remote canvas infrastructure for remoting instead. Differential Revision: https://phabricator.services.mozilla.com/D194351
2023-12-18 18:10:46 +00:00
WeakPtr<SharedContextWebgl> mSharedContext;
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
// If this snapshot has been copied into a cached texture handle.
RefPtr<TextureHandle> mHandle;
};
Bug 1754130 - Support presenting a WebGLFramebuffer to its own swap chain without opaque FB. r=aosmond,jgilbert 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
2022-02-11 19:49:56 +00:00
} // namespace mozilla::gfx
Bug 1754130 - Implement SourceSurfaceWebgl for faster snapshots of DrawTargetWebgl. r=aosmond Now that each DrawTargetWebgl shares the same WebGL context, we can efficiently draw snapshots of one DrawTargetWebgl to another without requiring any readback or error-prone driver-provided shared context/resource mechanism. We just need to simply pass the WebGL texture from one target to the other, and use it like any other texture. This provides SourceSurfaceWebgl to store and pass along that WebGL texture. It is largely modeled off of SourceSurfaceSkia in terms of its copy-on-write behavior. There are three noteworthy state changes that it must track from DrawTargetWebgl - when the framebuffer contents is changing, when the framebuffer is being destroyed, and when any cached texture handle separate from a framebuffer is also being destroyed. It will copy, orphan, or read back data as appropriate to handle each case. If it needs to be mapped, it just forces a read back of the data into a CPU surface that can be mapped as requested. Differential Revision: https://phabricator.services.mozilla.com/D138118
2022-02-11 19:49:55 +00:00
#endif /* MOZILLA_GFX_SOURCESURFACEWEBGL_H_ */
Reference in New Issue Copy Permalink