In general, the canvas text-drawing code makes two passes over the string, one to measure it and the second to draw.
Each time, it has to find individual direction runs and create a separate gfxTextRun for each.
However, in the (common) case of a simple unidirectional string, we're only going to have a single run,
so it's wasteful to construct it twice; the CanvasBidiProcessor can just re-use the run from the measurement
pass when it needs to draw.
In particular, this will apply to pdf.js drawing, where each glyph is handled in a separate fillText call.
Many other uses of canvas text should also benefit somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D145426
This enables an offscreen-canvas Worker to do text rendering, but only with system-installed fonts
because we don't yet have a FontFaceSet available in the Worker. (That's bug 1758946.)
Differential Revision: https://phabricator.services.mozilla.com/D144188
These need to be atomic so that they can be accessed by canvas code when running on a worker thread
without calling main-thread-only Preferences APIs.
Depends on D144185
Differential Revision: https://phabricator.services.mozilla.com/D144186
We don't need to null-check the mCanvasElement and mDocShell members in these methods,
and bail out if neither is provided, because in that case the following GetPresShell() call
will return null and we'll bail out there anyhow.
Removing these extra checks will simplify the changes involved in enabling the canvas code
to be used in a Worker context, where it is not connected to a document.
Depends on D144184
Differential Revision: https://phabricator.services.mozilla.com/D144185
Nothing uses this member, so remove it to make it clear we don't need to provide it
when setting up a CanvasRenderingContext2D.
Differential Revision: https://phabricator.services.mozilla.com/D144184
This requires updating a couple of our old dom/canvas mochitests that assume the size element
of the font attribute will be serialized as specified, which conflicts with the current spec
requirement.
On the other hand, this also resolves a few current WPT test failures that are specifically
testing the behavior described in the spec (e.g. a size specified as percentage gets serialized
as the computed px value).
Differential Revision: https://phabricator.services.mozilla.com/D144812
Currently calling Pattern::Clone() produces a heap-allocated Pattern with RefPtrs
to any internal resources such as SourceSurfaces or GradientStops. While this is
okay if the Pattern is transient, this causes problems if the clone is long-lived
and causes via the RefPtr the stored resource to stay alive, even when there are
no other external references to the resource.
In the case of DrawTargetWebgl's PathCache, we need to be able to create Pattern
clones that have internal weak references, while also still supporting the original
use-case of strong references. To this end we template-ize some of the Pattern
derivatives so that we can make either strong or weak versions according to use-case.
This case way we store a weak clone of a Pattern in the PathCache key, the reference
will automatically invalidate itself when all other external strong references to it
go away, without having to do external crawling of the PathCache to constantly prune
the last reference manually.
Differential Revision: https://phabricator.services.mozilla.com/D144381
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
This patch adds support for including the canvas contents in Firefox
Screenshots for Canvas 2D, WebGL and WebGPU. It is already working for
context's created through an OffscreenCanvas, but we failed to hook up
the main thread path after refactoring in previous bugs.
Differential Revision: https://phabricator.services.mozilla.com/D144310
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
This patch adds support for including the canvas contents in Firefox
Screenshots for Canvas 2D, WebGL and WebGPU. It is already working for
context's created through an OffscreenCanvas, but we failed to hook up
the main thread path after refactoring in previous bugs.
Differential Revision: https://phabricator.services.mozilla.com/D144310
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
Canvas 2D needs paint callbacks from the OffscreenCanvas display
pipeline so that it knows when to reinvalidate. They were disabled which
meant only the first frame was rendered.
Differential Revision: https://phabricator.services.mozilla.com/D144006
With this new approach, Shmem instances will now have their handles
transferred inline within messages as attachments, rather than being
associated with their actors and sent in separate messages.
This has a few advantages:
* The implementation is much simpler
* Releasing all references to a Shmem will automatically destroy it by
RAII, rather than leaking the shared memory region until the toplevel
actor is destroyed, removing the need for types like RaiiShmem.
* This allows re-transmitting Shmem instances to another process, as we
don't close the shared memory region handle upon receiving it.
But also has a disadvantage that because we keep alive the shared memory
region's handle until the shmem is destroyed, so that it can be
re-transmitted, we may end up using more FDs or HANDLEs while running.
This patch intentionally doesn't change or simplify callsites, removing
APIs like RaiiShmem, in order to make it easier to revert if this causes
issues on platforms like Linux due to FD exhaustion. If we don't run
into increased resource exhaustion problems, we can make these changes
in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D140211
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
- it's likely an oblivion from the fix for bug 1716622;
- so just add a check on the final length of the buffer to be under the limit of 2Gb.
Differential Revision: https://phabricator.services.mozilla.com/D143066
- It'll helpful to generate some ImageBitmap in the worker instead passing some
Uint8Clamped array from the worker to the main thread.
- Hence it will reduce memory footprint and improve performance in pdf.js.
Differential Revision: https://phabricator.services.mozilla.com/D143019
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
Initializing platform encoders often takes some time and the frame
rate measured is lower than actual number when the counting starts as
soon as connection established. Delaying the measurement until there
is at least some frame encoded makes it more accurate.
Differential Revision: https://phabricator.services.mozilla.com/D141513
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
There weren't that many uses of the existing typedef, so it seemed like
it might be worthwhile to just replace all uses of the previous typedef
with the stl-like one.
Differential Revision: https://phabricator.services.mozilla.com/D142705
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
Two issues:
The result of scaling & premultiply is order critical, the previous order for ImageData was scale > premultiply, the other image sources were premultiplied by default so didn't expose this issue. Reorder in the ImageData and common code paths (the original order followed the w3c spec order of operations - maybe the spec needs amending).
The ImageData path did not set the premultiplied flag of the resulting ImageBitmap correctly so the image would be premultiplied again in PrepareForDrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D139700
In certain use-cases where we support layered drawing to Skia above a WebGL context, we can
repeatedly oscillate between clearing the Skia layer, drawing to it, then flushing it to
the WebGL context to fulfill an accelerated drawing request. For example, StrokeLine followed
by DrawSurface, repeated in a cycle, will cause each StrokeLine request to go to the layer,
and then the following DrawSurface request will go to the WebGL context, with clearing and
flushing of the Skia layer in between.
The original intent of the code was that the performance benefits of accelerated drawing
would compensate for the occasional cost of flushing. However, in practice, this turns out
not to be true and repeated clearing and flushing costs for the Skia layering can dominate
the overall performance. We really just want to continue drawing into the Skia layer as
long as possible if some fallback causes us to initially set it up and use it. While not
ideal, it prevents from bad performance cliffs from occuring where flushing happens more
than once in a frame.
Differential Revision: https://phabricator.services.mozilla.com/D141270