mozilla
/
gecko-dev
зеркало из https://github.com/mozilla/gecko-dev.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
gecko-dev/dom/canvas/DrawTargetWebgl.h

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

457 строки
18 KiB
C
Исходник Обычный вид История

Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +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 _MOZILLA_GFX_DRAWTARGETWEBGL_H
#define _MOZILLA_GFX_DRAWTARGETWEBGL_H
#include "mozilla/gfx/2D.h"
#include "mozilla/LinkedList.h"
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
#include "mozilla/WeakPtr.h"
Bug 1755458 - Use threadlocal shared WebGL context for accelerated canvas. r=lsalzman Because ClientWebGLContext is single threaded, we need a different SharedContext for each thread that an accelerated Canvas2D is created for. Differential Revision: https://phabricator.services.mozilla.com/D141116
2022-03-15 20:37:30 +03:00
#include "mozilla/ThreadLocal.h"
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
#include <vector>
namespace mozilla {
class ClientWebGLContext;
class WebGLBufferJS;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
class WebGLFramebufferJS;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
class WebGLProgramJS;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
class WebGLRenderbufferJS;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
class WebGLTextureJS;
class WebGLUniformLocationJS;
class WebGLVertexArrayJS;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
namespace layers {
class SurfaceDescriptor;
}
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
namespace gfx {
class DataSourceSurface;
class DrawTargetSkia;
class DrawTargetWebgl;
Bug 1745556 - Cache paths to textures to avoid falling back to Skia. r=gfx-reviewers,aosmond This generalizes the CacheEntry infrastructure to implement path caching. This allows us to cache recently drawn paths to a texture which can be then drawn without falling back to Skia. Paths using simple solid color patterns will be drawn as alpha masks that can then have the color applied in the shader. For now, other pattern types have the pattern baked into the texture to avoid having to complicate the shader setup for now. In the future, other pattern types could be supported with new shaders to allow those to be cached as alpha masks as well. In the service of this, comparison and cloning operators were added to the Pattern classes to make remembering and matching against them easier for cache entries. Differential Revision: https://phabricator.services.mozilla.com/D135261
2022-01-14 20:30:21 +03:00
class PathSkia;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
class SourceSurfaceSkia;
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 22:49:55 +03:00
class SourceSurfaceWebgl;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
class TextureHandle;
class SharedTexture;
class SharedTextureHandle;
class StandaloneTexture;
class GlyphCache;
Bug 1745556 - Cache paths to textures to avoid falling back to Skia. r=gfx-reviewers,aosmond This generalizes the CacheEntry infrastructure to implement path caching. This allows us to cache recently drawn paths to a texture which can be then drawn without falling back to Skia. Paths using simple solid color patterns will be drawn as alpha masks that can then have the color applied in the shader. For now, other pattern types have the pattern baked into the texture to avoid having to complicate the shader setup for now. In the future, other pattern types could be supported with new shaders to allow those to be cached as alpha masks as well. In the service of this, comparison and cloning operators were added to the Pattern classes to make remembering and matching against them easier for cache entries. Differential Revision: https://phabricator.services.mozilla.com/D135261
2022-01-14 20:30:21 +03:00
class PathCache;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
// DrawTargetWebgl implements a subset of the DrawTarget API suitable for use
// by CanvasRenderingContext2D. It maps these to a client WebGL context so that
// they can be accelerated where possible by WebGL. It manages both routing to
// appropriate shaders and texture allocation/caching for surfaces. For commands
// that are not feasible to accelerate with WebGL, it mirrors state to a backup
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
// DrawTargetSkia that can be used as a fallback software renderer. Multiple
// instances of DrawTargetWebgl within a process will actually share a single
// WebGL context so that data can be more easily interchanged between them and
// also to enable more reasonable limiting of resource usage.
class DrawTargetWebgl : public DrawTarget, public SupportsWeakPtr {
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
friend class SharedTextureHandle;
friend class StandaloneTexture;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
friend class TextureHandle;
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 22:49:55 +03:00
friend class SourceSurfaceWebgl;
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
friend class AutoSaveContext;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
public:
MOZ_DECLARE_REFCOUNTED_VIRTUAL_TYPENAME(DrawTargetWebgl, override)
private:
IntSize mSize;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
RefPtr<WebGLFramebufferJS> mFramebuffer;
RefPtr<WebGLTextureJS> mTex;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
RefPtr<DrawTargetSkia> mSkia;
// The currently cached snapshot of the WebGL context
RefPtr<DataSourceSurface> mSnapshot;
// Whether or not the Skia target has valid contents and is being drawn to
bool mSkiaValid = false;
Bug 1745556 - Support layering of Skia and WebGL contexts in accelerated canvas. r=gfx-reviewers,aosmond Reading back from the WebGL context to the Skia context if we need to fall back software rasterization can be extremely expensive. In general, it is better to try to avoid this by rasterizing primitives in software and then uploading them to a texture. This generalizes that idea so that when using the default source-over blend mode, the Skia context can function as a layer that accumulates recently drawn primitives and blends them via source-over to the WebGL context when a flush is necessary. Differential Revision: https://phabricator.services.mozilla.com/D135260
2022-01-14 20:30:21 +03:00
// Whether or not Skia layering over the WebGL context is enabled
bool mSkiaLayer = false;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
// Whether or not the WebGL context has valid contents and is being drawn to
bool mWebglValid = false;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
// Whether or not the clip state has changed since last used by SharedContext.
bool mClipDirty = true;
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
// The framebuffer has been modified and should be copied to the swap chain.
bool mNeedsPresent = true;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
RefPtr<TextureHandle> mSnapshotTexture;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
Bug 1762523 - Add performance profiling to DrawTargetWebgl. r=aosmond,gfx-reviewers This adds OnEvent hooks to DrawTargetWebgl for various events so that profile counters may be maintained each frame. These profile counters try to determine if a software fallback happened or an uncacheable event occurs that requires either uploading data to the GPU or reading back from the GPU, events which can cause substantial slowdown if they happen repeatedly even without an explicit fallback to software rasterization. When it is determined a threshold has been reached (as controlled by some prefs), RequiresRefresh() in PersistentBufferProvider is used to signal that we should recreate the PersistentBufferProvider of a different type and thus disable acceleration. Differential Revision: https://phabricator.services.mozilla.com/D142646
2022-04-04 18:50:48 +03:00
// UsageProfile stores per-frame counters for significant profiling events
// that assist in determining whether acceleration should still be used for
// a Canvas2D user.
struct UsageProfile {
uint32_t mFailedFrames = 0;
uint32_t mFrameCount = 0;
uint32_t mCacheMisses = 0;
uint32_t mCacheHits = 0;
uint32_t mUncachedDraws = 0;
uint32_t mLayers = 0;
uint32_t mReadbacks = 0;
uint32_t mFallbacks = 0;
void BeginFrame();
void EndFrame();
bool RequiresRefresh() const;
void OnCacheMiss() { ++mCacheMisses; }
void OnCacheHit() { ++mCacheHits; }
void OnUncachedDraw() { ++mUncachedDraws; }
void OnLayer() { ++mLayers; }
void OnReadback() { ++mReadbacks; }
void OnFallback() { ++mFallbacks; }
};
UsageProfile mProfile;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
// SharedContext stores most of the actual WebGL state that may be used by
// any number of DrawTargetWebgl's that use it. Foremost, it holds the actual
// WebGL client context, programs, and buffers for mapping to WebGL.
// Secondarily, it holds shared caches for surfaces, glyphs, paths, and
// shadows so that each DrawTargetWebgl does not require its own cache. It is
// important that SetTarget is called to install the current DrawTargetWebgl
// before actually using the SharedContext, as the individual framebuffers
// and viewport are still maintained in DrawTargetWebgl itself.
class SharedContext : public mozilla::RefCounted<SharedContext>,
public mozilla::SupportsWeakPtr {
public:
MOZ_DECLARE_REFCOUNTED_TYPENAME(SharedContext)
SharedContext();
~SharedContext();
WeakPtr<DrawTargetWebgl> mCurrentTarget;
IntSize mViewportSize;
IntRect mClipRect;
RefPtr<ClientWebGLContext> mWebgl;
// Avoid spurious state changes by caching last used state.
RefPtr<WebGLProgramJS> mLastProgram;
RefPtr<WebGLTextureJS> mLastTexture;
Bug 1764948 - Implement anti-aliasing for DrawTargetWebgl. r=gfx-reviewers,nical This provides basic distange-to-edge anti-aliasing for accelerated rectangle drawing in DrawTargetWebgl. It tracks the distance to each edge in screen space for each edge of the rectangle. These distances are passed down to the fragment shader in an interpolant and then the smallest one is selected from them to represent the final opacity of the pixel. We also need to extrude the rectangle outward by a pixel to account for the AA region. This is based off WebRender's AA strategy as outlined in bug 1764364. Differential Revision: https://phabricator.services.mozilla.com/D143832
2022-04-16 06:50:26 +03:00
bool mDirtyViewport = true;
bool mDirtyAA = true;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
// WebGL shader resources
RefPtr<WebGLBufferJS> mVertexBuffer;
RefPtr<WebGLVertexArrayJS> mVertexArray;
RefPtr<WebGLProgramJS> mSolidProgram;
Bug 1764948 - Implement anti-aliasing for DrawTargetWebgl. r=gfx-reviewers,nical This provides basic distange-to-edge anti-aliasing for accelerated rectangle drawing in DrawTargetWebgl. It tracks the distance to each edge in screen space for each edge of the rectangle. These distances are passed down to the fragment shader in an interpolant and then the smallest one is selected from them to represent the final opacity of the pixel. We also need to extrude the rectangle outward by a pixel to account for the AA region. This is based off WebRender's AA strategy as outlined in bug 1764364. Differential Revision: https://phabricator.services.mozilla.com/D143832
2022-04-16 06:50:26 +03:00
RefPtr<WebGLUniformLocationJS> mSolidProgramViewport;
RefPtr<WebGLUniformLocationJS> mSolidProgramAA;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
RefPtr<WebGLUniformLocationJS> mSolidProgramTransform;
RefPtr<WebGLUniformLocationJS> mSolidProgramColor;
RefPtr<WebGLProgramJS> mImageProgram;
Bug 1764948 - Implement anti-aliasing for DrawTargetWebgl. r=gfx-reviewers,nical This provides basic distange-to-edge anti-aliasing for accelerated rectangle drawing in DrawTargetWebgl. It tracks the distance to each edge in screen space for each edge of the rectangle. These distances are passed down to the fragment shader in an interpolant and then the smallest one is selected from them to represent the final opacity of the pixel. We also need to extrude the rectangle outward by a pixel to account for the AA region. This is based off WebRender's AA strategy as outlined in bug 1764364. Differential Revision: https://phabricator.services.mozilla.com/D143832
2022-04-16 06:50:26 +03:00
RefPtr<WebGLUniformLocationJS> mImageProgramViewport;
RefPtr<WebGLUniformLocationJS> mImageProgramAA;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
RefPtr<WebGLUniformLocationJS> mImageProgramTransform;
RefPtr<WebGLUniformLocationJS> mImageProgramTexMatrix;
RefPtr<WebGLUniformLocationJS> mImageProgramTexBounds;
RefPtr<WebGLUniformLocationJS> mImageProgramColor;
RefPtr<WebGLUniformLocationJS> mImageProgramSwizzle;
RefPtr<WebGLUniformLocationJS> mImageProgramSampler;
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 22:49:55 +03:00
// Scratch framebuffer used to wrap textures for miscellaneous utility ops.
RefPtr<WebGLFramebufferJS> mScratchFramebuffer;
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
uint32_t mMaxTextureSize = 0;
CompositionOp mLastCompositionOp = CompositionOp::OP_SOURCE;
// A most-recently-used list of allocated texture handles.
LinkedList<RefPtr<TextureHandle>> mTextureHandles;
size_t mNumTextureHandles = 0;
// User data key linking a SourceSurface with its TextureHandle.
UserDataKey mTextureHandleKey = {0};
// User data key linking a SourceSurface with its shadow blur TextureHandle.
UserDataKey mShadowTextureKey = {0};
// User data key linking a ScaledFont with its GlyphCache.
UserDataKey mGlyphCacheKey = {0};
// List of all GlyphCaches currently allocated to fonts.
LinkedList<GlyphCache> mGlyphCaches;
// Cache of rasterized paths.
UniquePtr<PathCache> mPathCache;
// Collection of allocated shared texture pages that may be shared amongst
// many handles.
std::vector<RefPtr<SharedTexture>> mSharedTextures;
// Collection of allocated standalone textures that have a single assigned
// handle.
std::vector<RefPtr<StandaloneTexture>> mStandaloneTextures;
size_t mUsedTextureMemory = 0;
size_t mTotalTextureMemory = 0;
const Matrix& GetTransform() const { return mCurrentTarget->mTransform; }
bool IsContextLost() const;
bool Initialize();
bool CreateShaders();
void SetBlendState(CompositionOp aOp);
void SetClipRect(const IntRect& aClipRect) { mClipRect = aClipRect; }
bool IsCurrentTarget(DrawTargetWebgl* aDT) const {
return aDT == mCurrentTarget;
}
bool SetTarget(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 22:49:55 +03:00
// Reset the current target.
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
void ClearTarget() { mCurrentTarget = nullptr; }
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 22:49:55 +03:00
// Reset the last used texture to force binding next use.
void ClearLastTexture();
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
bool SupportsPattern(const Pattern& aPattern);
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 22:49:55 +03:00
void InitTexParameters(WebGLTextureJS* aTex);
bool ReadInto(uint8_t* aDstData, int32_t aDstStride, SurfaceFormat aFormat,
const IntRect& aBounds, TextureHandle* aHandle = nullptr);
already_AddRefed<DataSourceSurface> ReadSnapshot(
TextureHandle* aHandle = nullptr);
already_AddRefed<TextureHandle> WrapSnapshot(const IntSize& aSize,
SurfaceFormat aFormat,
RefPtr<WebGLTextureJS> aTex);
already_AddRefed<TextureHandle> CopySnapshot();
already_AddRefed<WebGLTextureJS> GetCompatibleSnapshot(
SourceSurface* aSurface);
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
bool UploadSurface(DataSourceSurface* aData, SurfaceFormat aFormat,
const IntRect& aSrcRect, const IntPoint& aDstOffset,
bool aInit);
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
bool DrawRectAccel(const Rect& aRect, const Pattern& aPattern,
const DrawOptions& aOptions,
Maybe<DeviceColor> aMaskColor = Nothing(),
RefPtr<TextureHandle>* aHandle = nullptr,
bool aTransformed = true, bool aClipped = true,
bool aAccelOnly = false, bool aForceUpdate = false,
const StrokeOptions* aStrokeOptions = nullptr);
bool DrawPathAccel(const Path* aPath, const Pattern& aPattern,
const DrawOptions& aOptions,
Bug 1761404 - Add DrawTarget DrawShadow API call. r=jrmuizel,gfx-reviewers This implements a new DrawTarget API call, DrawShadow. This can be used to draw the shadow of a given Path and Pattern. Unlike DrawSurfaceWithShadow, this only draws the shadow to simplify the resulting implementation. DrawTarget provides a default implementation that will draw a blurred shadow to a transient surface before handing it off to DrawSurfaceWithShadow, allowing existing DrawTarget implementations to function without having to implement the new API at all. Within DrawTargetWebgl, DrawShadow allows direct caching of the shadow in the existing PathCache mechanism, unlike DrawSurfaceWithShadow which would usually be called with different transient surfaces every time, even if the input patterns actually matched. CanvasRenderingContext2D is modified to call DrawShadow when only a shadow needs to be applied without any filter. AdjustedTarget is modified to wrap the necessary DrawTarget draw calls so they can be dispatched appropriately. Since a lot of redundant shadow parameters are shared between DrawShadow and DrawSurfaceWithShadow, and since a lot of consumers of these functions need to also pass around these parameters, this also bundles these into a new ShadowOptions structure to make this easier. Differential Revision: https://phabricator.services.mozilla.com/D142026
2022-04-01 22:03:29 +03:00
const StrokeOptions* aStrokeOptions = nullptr,
const ShadowOptions* aShadow = nullptr,
bool aCacheable = true);
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
bool FillGlyphsAccel(ScaledFont* aFont, const GlyphBuffer& aBuffer,
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
const Pattern& aPattern, const DrawOptions& aOptions,
bool aUseSubpixelAA);
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
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 22:49:56 +03:00
void PruneTextureHandle(const RefPtr<TextureHandle>& aHandle);
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
bool PruneTextureMemory(size_t aMargin = 0, bool aPruneUnused = true);
bool RemoveSharedTexture(const RefPtr<SharedTexture>& aTexture);
bool RemoveStandaloneTexture(const RefPtr<StandaloneTexture>& aTexture);
void UnlinkSurfaceTextures();
void UnlinkSurfaceTexture(const RefPtr<TextureHandle>& aHandle);
void UnlinkGlyphCaches();
};
RefPtr<SharedContext> mSharedContext;
Bug 1755458 - Use threadlocal shared WebGL context for accelerated canvas. r=lsalzman Because ClientWebGLContext is single threaded, we need a different SharedContext for each thread that an accelerated Canvas2D is created for. Differential Revision: https://phabricator.services.mozilla.com/D141116
2022-03-15 20:37:30 +03:00
static MOZ_THREAD_LOCAL(SharedContext*) sSharedContext;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
public:
DrawTargetWebgl();
~DrawTargetWebgl();
static already_AddRefed<DrawTargetWebgl> Create(const IntSize& aSize,
SurfaceFormat aFormat);
bool Init(const IntSize& aSize, SurfaceFormat aFormat);
Bug 1742340 - Handle WebGL context loss in DrawTargetWebgl. r=jrmuizel,gfx-reviewers Differential Revision: https://phabricator.services.mozilla.com/D131826
2021-11-30 19:59:42 +03:00
bool IsValid() const override;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
DrawTargetType GetType() const override {
return DrawTargetType::HARDWARE_RASTER;
}
BackendType GetBackendType() const override { return BackendType::WEBGL; }
IntSize GetSize() const override { return mSize; }
already_AddRefed<SourceSurface> Snapshot() override;
already_AddRefed<SourceSurface> GetBackingSurface() override;
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
void DetachAllSnapshots() override;
void BeginFrame(const IntRect& aPersistedRect);
void EndFrame();
Bug 1762523 - Add performance profiling to DrawTargetWebgl. r=aosmond,gfx-reviewers This adds OnEvent hooks to DrawTargetWebgl for various events so that profile counters may be maintained each frame. These profile counters try to determine if a software fallback happened or an uncacheable event occurs that requires either uploading data to the GPU or reading back from the GPU, events which can cause substantial slowdown if they happen repeatedly even without an explicit fallback to software rasterization. When it is determined a threshold has been reached (as controlled by some prefs), RequiresRefresh() in PersistentBufferProvider is used to signal that we should recreate the PersistentBufferProvider of a different type and thus disable acceleration. Differential Revision: https://phabricator.services.mozilla.com/D142646
2022-04-04 18:50:48 +03:00
bool RequiresRefresh() const { return mProfile.RequiresRefresh(); }
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
bool LockBits(uint8_t** aData, IntSize* aSize, int32_t* aStride,
SurfaceFormat* aFormat, IntPoint* aOrigin = nullptr) override;
void ReleaseBits(uint8_t* aData) override;
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
void Flush() override {}
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
void DrawSurface(
SourceSurface* aSurface, const Rect& aDest, const Rect& aSource,
const DrawSurfaceOptions& aSurfOptions = DrawSurfaceOptions(),
const DrawOptions& aOptions = DrawOptions()) override;
void DrawFilter(FilterNode* aNode, const Rect& aSourceRect,
const Point& aDestPoint,
const DrawOptions& aOptions = DrawOptions()) override;
void DrawSurfaceWithShadow(SourceSurface* aSurface, const Point& aDest,
Bug 1761404 - Add DrawTarget DrawShadow API call. r=jrmuizel,gfx-reviewers This implements a new DrawTarget API call, DrawShadow. This can be used to draw the shadow of a given Path and Pattern. Unlike DrawSurfaceWithShadow, this only draws the shadow to simplify the resulting implementation. DrawTarget provides a default implementation that will draw a blurred shadow to a transient surface before handing it off to DrawSurfaceWithShadow, allowing existing DrawTarget implementations to function without having to implement the new API at all. Within DrawTargetWebgl, DrawShadow allows direct caching of the shadow in the existing PathCache mechanism, unlike DrawSurfaceWithShadow which would usually be called with different transient surfaces every time, even if the input patterns actually matched. CanvasRenderingContext2D is modified to call DrawShadow when only a shadow needs to be applied without any filter. AdjustedTarget is modified to wrap the necessary DrawTarget draw calls so they can be dispatched appropriately. Since a lot of redundant shadow parameters are shared between DrawShadow and DrawSurfaceWithShadow, and since a lot of consumers of these functions need to also pass around these parameters, this also bundles these into a new ShadowOptions structure to make this easier. Differential Revision: https://phabricator.services.mozilla.com/D142026
2022-04-01 22:03:29 +03:00
const ShadowOptions& aShadow,
CompositionOp aOperator) override;
void DrawShadow(const Path* aPath, const Pattern& aPattern,
const ShadowOptions& aShadow, const DrawOptions& aOptions,
const StrokeOptions* aStrokeOptions = nullptr) override;
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
void ClearRect(const Rect& aRect) override;
void CopySurface(SourceSurface* aSurface, const IntRect& aSourceRect,
const IntPoint& aDestination) override;
void FillRect(const Rect& aRect, const Pattern& aPattern,
const DrawOptions& aOptions = DrawOptions()) override;
void StrokeRect(const Rect& aRect, const Pattern& aPattern,
const StrokeOptions& aStrokeOptions = StrokeOptions(),
const DrawOptions& aOptions = DrawOptions()) override;
void StrokeLine(const Point& aStart, const Point& aEnd,
const Pattern& aPattern,
const StrokeOptions& aStrokeOptions = StrokeOptions(),
const DrawOptions& aOptions = DrawOptions()) override;
void Stroke(const Path* aPath, const Pattern& aPattern,
const StrokeOptions& aStrokeOptions = StrokeOptions(),
const DrawOptions& aOptions = DrawOptions()) override;
void Fill(const Path* aPath, const Pattern& aPattern,
const DrawOptions& aOptions = DrawOptions()) override;
void SetPermitSubpixelAA(bool aPermitSubpixelAA) override;
void FillGlyphs(ScaledFont* aFont, const GlyphBuffer& aBuffer,
const Pattern& aPattern,
const DrawOptions& aOptions = DrawOptions()) override;
void StrokeGlyphs(ScaledFont* aFont, const GlyphBuffer& aBuffer,
const Pattern& aPattern,
const StrokeOptions& aStrokeOptions = StrokeOptions(),
const DrawOptions& aOptions = DrawOptions()) override;
void Mask(const Pattern& aSource, const Pattern& aMask,
const DrawOptions& aOptions = DrawOptions()) override;
void MaskSurface(const Pattern& aSource, SourceSurface* aMask, Point aOffset,
const DrawOptions& aOptions = DrawOptions()) override;
bool Draw3DTransformedSurface(SourceSurface* aSurface,
const Matrix4x4& aMatrix) override;
void PushClip(const Path* aPath) override;
void PushClipRect(const Rect& aRect) override;
void PushDeviceSpaceClipRects(const IntRect* aRects,
uint32_t aCount) override;
void PopClip() override;
void PushLayer(bool aOpaque, Float aOpacity, SourceSurface* aMask,
const Matrix& aMaskTransform,
const IntRect& aBounds = IntRect(),
bool aCopyBackground = false) override {
MOZ_ASSERT(false);
}
void PushLayerWithBlend(
bool aOpaque, Float aOpacity, SourceSurface* aMask,
const Matrix& aMaskTransform, const IntRect& aBounds = IntRect(),
bool aCopyBackground = false,
CompositionOp aCompositionOp = CompositionOp::OP_OVER) override {
MOZ_ASSERT(false);
}
void PopLayer() override { MOZ_ASSERT(false); }
already_AddRefed<SourceSurface> CreateSourceSurfaceFromData(
unsigned char* aData, const IntSize& aSize, int32_t aStride,
SurfaceFormat aFormat) const override;
already_AddRefed<SourceSurface> OptimizeSourceSurface(
SourceSurface* aSurface) const override;
already_AddRefed<SourceSurface> OptimizeSourceSurfaceForUnknownAlpha(
SourceSurface* aSurface) const override;
already_AddRefed<SourceSurface> CreateSourceSurfaceFromNativeSurface(
const NativeSurface& aSurface) const override;
already_AddRefed<DrawTarget> CreateSimilarDrawTarget(
const IntSize& aSize, SurfaceFormat aFormat) const override;
bool CanCreateSimilarDrawTarget(const IntSize& aSize,
SurfaceFormat aFormat) const override;
RefPtr<DrawTarget> CreateClippedDrawTarget(const Rect& aBounds,
SurfaceFormat aFormat) override;
already_AddRefed<PathBuilder> CreatePathBuilder(
FillRule aFillRule = FillRule::FILL_WINDING) const override;
already_AddRefed<GradientStops> CreateGradientStops(
GradientStop* aStops, uint32_t aNumStops,
ExtendMode aExtendMode = ExtendMode::CLAMP) const override;
already_AddRefed<FilterNode> CreateFilter(FilterType aType) override;
void SetTransform(const Matrix& aTransform) override;
void* GetNativeSurface(NativeSurfaceType aType) 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 22:49:56 +03:00
Maybe<layers::SurfaceDescriptor> GetFrontBuffer();
bool CopySnapshotTo(DrawTarget* aDT);
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
operator std::string() const {
std::stringstream stream;
stream << "DrawTargetWebgl(" << this << ")";
return stream.str();
}
private:
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
bool SupportsPattern(const Pattern& aPattern) {
return mSharedContext->SupportsPattern(aPattern);
}
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 18:36:29 +03:00
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
bool PrepareContext(bool aClipped = true);
void DrawRectFallback(const Rect& aRect, const Pattern& aPattern,
const DrawOptions& aOptions,
Maybe<DeviceColor> aMaskColor, bool aTransform,
bool aClipped, const StrokeOptions* aStrokeOptions);
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
bool DrawRect(const Rect& aRect, const Pattern& aPattern,
const DrawOptions& aOptions,
Maybe<DeviceColor> aMaskColor = Nothing(),
RefPtr<TextureHandle>* aHandle = nullptr,
bool aTransformed = true, bool aClipped = true,
Bug 1745556 - Support drawing simple stroked geometry. r=jrmuizel This just tries to add in support for drawing certain stroked rects by reusing existing shaders and geometry. This solves some low-hanging fruit with certain test-cases while more general stroked geometry can be added at a later time. Differential Revision: https://phabricator.services.mozilla.com/D135259
2022-01-14 20:30:20 +03:00
bool aAccelOnly = false, bool aForceUpdate = false,
const StrokeOptions* aStrokeOptions = nullptr);
Bug 1745556 - Add support for stroked paths to path cache. r=gfx-reviewers,aosmond Differential Revision: https://phabricator.services.mozilla.com/D135902
2022-01-14 20:30:22 +03:00
void DrawPath(const Path* aPath, const Pattern& aPattern,
const DrawOptions& aOptions,
const StrokeOptions* aStrokeOptions = nullptr);
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
bool MarkChanged();
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
void ReadIntoSkia();
Bug 1745556 - Support layering of Skia and WebGL contexts in accelerated canvas. r=gfx-reviewers,aosmond Reading back from the WebGL context to the Skia context if we need to fall back software rasterization can be extremely expensive. In general, it is better to try to avoid this by rasterizing primitives in software and then uploading them to a texture. This generalizes that idea so that when using the default source-over blend mode, the Skia context can function as a layer that accumulates recently drawn primitives and blends them via source-over to the WebGL context when a flush is necessary. Differential Revision: https://phabricator.services.mozilla.com/D135260
2022-01-14 20:30:21 +03:00
void FlattenSkia();
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
bool FlushFromSkia();
void MarkSkiaChanged() {
if (!mSkiaValid) {
ReadIntoSkia();
Bug 1745556 - Support layering of Skia and WebGL contexts in accelerated canvas. r=gfx-reviewers,aosmond Reading back from the WebGL context to the Skia context if we need to fall back software rasterization can be extremely expensive. In general, it is better to try to avoid this by rasterizing primitives in software and then uploading them to a texture. This generalizes that idea so that when using the default source-over blend mode, the Skia context can function as a layer that accumulates recently drawn primitives and blends them via source-over to the WebGL context when a flush is necessary. Differential Revision: https://phabricator.services.mozilla.com/D135260
2022-01-14 20:30:21 +03:00
} else if (mSkiaLayer) {
FlattenSkia();
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
}
mWebglValid = false;
}
Bug 1745556 - Support layering of Skia and WebGL contexts in accelerated canvas. r=gfx-reviewers,aosmond Reading back from the WebGL context to the Skia context if we need to fall back software rasterization can be extremely expensive. In general, it is better to try to avoid this by rasterizing primitives in software and then uploading them to a texture. This generalizes that idea so that when using the default source-over blend mode, the Skia context can function as a layer that accumulates recently drawn primitives and blends them via source-over to the WebGL context when a flush is necessary. Differential Revision: https://phabricator.services.mozilla.com/D135260
2022-01-14 20:30:21 +03:00
void MarkSkiaChanged(const DrawOptions& aOptions);
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
bool ReadInto(uint8_t* aDstData, int32_t aDstStride);
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 22:49:55 +03:00
already_AddRefed<DataSourceSurface> ReadSnapshot();
already_AddRefed<TextureHandle> CopySnapshot();
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
void ClearSnapshot(bool aCopyOnWrite = true);
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
Bug 1754130 - Implement SharedContext for sharing WebGL state among many DrawTargetWebgls. r=aosmond Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and also related resources for drawing with it. Not a lot of new code has actually been added as this was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL context to be moved into SharedContext, while leaving any code that was only dealing with Skia software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state that is unique to each DrawTargetWebgl instance. Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer as the one that the WebGL context will draw to as well as to learn details about the viewport and other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl has now moved into SharedContext, so that SharedContext can easily access this for drawing as well as to provide for the goal of simplifying resource limiting. Differential Revision: https://phabricator.services.mozilla.com/D138117
2022-02-11 22:49:55 +03:00
bool CreateFramebuffer();
Bug 1755780 - Optimize DrawTargetWebgl for BGRA WebGL framebuffer. r=aosmond Currently within DrawTargetWebGL, the Skia framebuffer and external software surfaces are in BGRA, while the WebGL framebuffer is in RGBA. This requires swizzling all software surfaces to RGBA on upload and swizzling surfaces back to BGRA on readback. This can either require intermediate surfaces or extra costly processing. Now that CopyToSwapChain is available with support for a BGRA blit, we can remove these complications by just treating the WebGL framebuffer as if it was BGRA directly, so that any uploads or readbacks do not require a swizzle. Differential Revision: https://phabricator.services.mozilla.com/D139066
2022-02-21 20:33:09 +03:00
// PrepareContext may sometimes be used recursively. When this occurs, ensure
// that clip state is restored after the context is used.
struct AutoRestoreContext {
DrawTargetWebgl* mTarget;
IntRect mClipRect;
explicit AutoRestoreContext(DrawTargetWebgl* aTarget)
: mTarget(aTarget), mClipRect(aTarget->mSharedContext->mClipRect) {}
~AutoRestoreContext() {
mTarget->mSharedContext->SetClipRect(mClipRect);
mTarget->mClipDirty = true;
}
};
Bug 1739448 - Implement a prototype WebGL-backed Canvas2D. r=gfx-reviewers,nical,jrmuizel 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
2021-11-11 10:16:58 +03:00
};
} // namespace gfx
} // namespace mozilla
#endif // _MOZILLA_GFX_DRAWTARGETWEBGL_H