Because we cannot control the ordering of shutdown notification from
WorkerRef, we need to choose one centralized point to begin shutdown of
the main thread or the owning DOM worker. Since there are other objects
owned by CanvasManagerChild, we also switch to a ThreadSafeWorkerRef.
Differential Revision: https://phabricator.services.mozilla.com/D195120
Because we cannot control the ordering of shutdown notification from
WorkerRef, we need to choose one centralized point to begin shutdown of
the main thread or the owning DOM worker. Since there are other objects
owned by CanvasManagerChild, we also switch to a ThreadSafeWorkerRef.
Differential Revision: https://phabricator.services.mozilla.com/D195120
This patch adds a new layout profiling sub-category "LAYOUT_Printing" for the
markers added here.
I'm adding an "interval"-type marker ("AUTO_PROFILER_MARKER_TEXT") for the
function-calls that seem likely to occupy measurable amounts of time (due to
touching the filesystem or printer driver), vs. single-point-in-time markers
("PROFILER_MARKER_TEXT") for functions whose duration isn't particularly long
or interesting, or whose durations we're already measuring with other
closely-associated interval-markers.
Differential Revision: https://phabricator.services.mozilla.com/D191001
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
When we recreate the display list, e.g. after tabbing away, we need to
ensure we flush the OffscreenCanvas because our resource handles will be
invalidated. This requires the OffscreenCanvasDisplayHelper to know
which OffscreenCanvas it belongs to, and a worker reference if necessary
to do the dispatching for the flush. Otherwise we would require the
canvas to be updated manually by the web application to repaint.
Differential Revision: https://phabricator.services.mozilla.com/D184324
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Since HTMLCanvasElement has a lazily-created context, and the
RequestedFrameRefreshObserver will fail to watch the state when the
context is null, this patch adds a hook to try to re-register when
UpdateContext is called. The superclass calls UpdateContext after the
context is initially created.
Differential Revision: https://phabricator.services.mozilla.com/D181149
We've supported nsIPrincipal off-main-thread since bug 1443925, and
nsIPrincipal has been used as the JSPrincipals on workers and worklets
since bug 1804093.
This change updates the signature of these methods to match the main
thread, and provides the subject principal off-main-thread as well as on
the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D180158
The spec does not seem to require a current context, so there's no reason
to require it here. If later calls within
`HTMLCanvasElement::CaptureStream` need a current context, they'll have
their own failure messages which will hopefully clarify where exactly we
need the context to exist.
Differential Revision: https://phabricator.services.mozilla.com/D178985
The spec does not seem to require a current context, so there's no reason
to require it here. If later calls within
`HTMLCanvasElement::CaptureStream` need a current context, they'll have
their own failure messages which will hopefully clarify where exactly we
need the context to exist.
Differential Revision: https://phabricator.services.mozilla.com/D178985
This patch introduces random noises to data extraction functions of
canvas element and offscreen canvas. The random noise is based on the
random key of the cookieJarSettings and the image data itself.
The random noises would interfere the ability of fingerprinters that
use canvas data to fingerprint users. The random noise will make unique
canvas finerprint to for every browsing session. Therefore, fingerprinter
cannot use canvas fingerprint to tracker individuals across browsing
sessions.
Differential Revision: https://phabricator.services.mozilla.com/D175499
Same rg + sed shenanigans as the first patch.
There were two that could fail, both due to OOM:
* HTMLInputElement::AfterSetAttr: If we fail (only in the type=range
case) we end up with an old value without it being clamped by
min/max/step.
* HTMLBodyElement::AfterSetAttr: If we fail we won't peek up the
DocShell's frame margins and styling could be incorrect.
That seems better than having to deal with broken states after we've
already set the attribute.
Depends on D176069
Differential Revision: https://phabricator.services.mozilla.com/D176070
WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
This will allow time consuming tasks (copies, capture, etc.) along the pipe to
be grouped per-track-source when visualizing profiler markers.
Differential Revision: https://phabricator.services.mozilla.com/D160754
By default, BorrowSnapshot is pessimistic and forces DrawTargetWebgl to return a data snapshot on
the assumption that the snapshot might be used off thread. However, if we actually know the DrawTarget
we're going to be drawing the snapshot to, then we can check if they're both DrawTargetWebgls with
the same internal SharedContext. In that case, we can use a SourceSurfaceWebgl snapshot which can
pass through a GPU texture to the target. This requires us to plumb the DrawTarget down through
SurfaceFromElement all the way to DrawTargetWebgl to make this decision.
Differential Revision: https://phabricator.services.mozilla.com/D162176
Add a pref for MouseEvent.region since that wasn't un-exposed. No other
browser supports it so we can probably safely remove it, but just in
case.
Differential Revision: https://phabricator.services.mozilla.com/D152274
OffscreenCanvasDisplayHelper may call back into HTMLCanvasElement after
it has been unlinked and violate our assumption that
HTMLCanvasElement::InvalidateCanvasPlaceholder is only called when we
have an OffscreenCanvas member. This patch makes it so that we clear the
relevant references during unlinking so that we don't make this mistake.
Differential Revision: https://phabricator.services.mozilla.com/D139380
This patch ensures we return an empty surface as per the spec when
the OffscreenCanvas passed into CreatePattern and DrawImage has no
context bound to it.
Differential Revision: https://phabricator.services.mozilla.com/D139127
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
This patch ensures that we only update the external image resource for
WebGPU when there has been an actual change for the resource. In order
to guarantee this, we wait for the present to complete, and only then
issue the update. WebRenderBridgeChild::SendResourceUpdates will also
trigger a frame generation if any resources were changed, which means we
don't need to trigger a paint on the frame itself anymore.
Note that we still have a race condition when we write into the
MemoryTextureHost while in PresentCallback, and the renderer thread may
be accessing the pixel data to upload to the GPU.
Differential Revision: https://phabricator.services.mozilla.com/D138349
