In DrawTargetRecording::CreateSimilarDrawTarget, we would originally
create a new DrawTargetRecording. For resources that are shared, such as
SVG patterns, we would do the same work for each blob image tile. This
can get expensive if the pattern is large. Now we check a size
threshold, and if passed, we create a DrawTargetSkia backed by a
SourceSurfaceSharedData. When we want a snapshot, we now try to get the
shared surface instead if available. The recording infrastructure
already knows how to handle the lifetimes and use of external IDs for
shared surfaces, so now we rasterize the pattern once for all the blob
tiles. In an ideal world we would do this in the compositor process
once, but that requires more changes, and this is useful as a stopgap in
the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D63903
--HG--
extra : moz-landing-system : lando
WebRender expects drop shadow dx/dy to be in user space, which is a floating point value.
Before this, a dx/dy such as (0.2, 0.2) was truncated to (0, 0) resulting in no offset of the shadow.
Differential Revision: https://phabricator.services.mozilla.com/D63442
--HG--
extra : moz-landing-system : lando
this change adds an ability to create WebGPU textures, views, and samplers
Differential Revision: https://phabricator.services.mozilla.com/D63595
--HG--
extra : source : 8f51a5fac21cb52e2ddb647f0b99a9bfccb41f6a
Previously we only saved shaders to disk on the tenth frame, meaning
shaders compiled afterwards would not be cached and would need to be
recompiled in future runs of the application. This change makes it so
that we cache shaders to disk regardless of which frame they are
compiled in.
We continue to treat only the shaders used within the first ten frames
as the "startup shaders", meaning only those ones will be loaded on
next startup. Caching as many other shaders as possible is still
beneficial, however, as they are loaded on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D62748
--HG--
extra : moz-landing-system : lando
We are intending to advance the toolkit.shutdown.lateWriteChecksStage
pref, to collect information (and crash on DEBUG) about writes which
happen during and after the xpcom-shutdown-threads notification. This
is producing failures in the PrintTargetPDF.cpp destructor because
we end up calling write_func and writing to (I presume) the target
PDF. This _feels_ like something we can just skip, so that's the
review request I am sending, but please let me know if it's critical
that we write to this file during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D63218
--HG--
extra : moz-landing-system : lando
In some cases (such as the case from this bug) the display list contains a
"hoisted" scrollinfo display item, which indicates the presence of a scroller
inside an inactive layer subtree (e.g. a div with certain kinds of filters).
The scrollinfo display item is "hoisted" outside the display list subtree so
that it doesn't get flattened away inside the inactive subtree. That display
item then causes the compositor hit-test regions to updated appropriately so
that APZ knows about the scrollframe inside the flattened content. This in turn
allows APZ to request main-thread scrolling for that scrollframe when input
events are directed to it.
With the WebRender codepath, the information represented by the hoisted
scrollinfo display item was being lost instead of being propagated to the
compositor. This was because the mechanism used for information propagation is
different (WebRender commands vs layers EventRegions). This patch ensures that
the scrollinfo display items also generate appropriate WebRender commands so
that the information is not lost, and WR knows about the scrollframe inside
the flattened content.
The patch includes:
- A code movement in nsGfxScrolllFrame.cpp so that necessary information can
be provided to the nsDisplayScrollInfoLayer constructor
- Updates to nsDisplayScrollInfoLayer members to store the necessary information
- Addition of nsDisplayScrollInfoLayer::CreateWebRenderCommands which propagates
the information to the WR display list
- A test to exercise the changes.
Differential Revision: https://phabricator.services.mozilla.com/D63869
--HG--
extra : moz-landing-system : lando
This makes its calculation correct even for content inside RDM.
I don't think coordinatesRelativeToScreen() is currently used inside RDM,
but it might be in the future, and in any case it's good for it to be
conceptually correct.
Differential Revision: https://phabricator.services.mozilla.com/D63752
--HG--
extra : moz-landing-system : lando
This patch folds the raster scale and device pixel scale effects into
the font transform, instead of the font size itself. This helps minimize
the quantization effect given the font size is stored as an Au
(resolution of 1/60) instead of an f32, and the shader does not
replicate that effect.
Differential Revision: https://phabricator.services.mozilla.com/D63641
--HG--
extra : moz-landing-system : lando
It seems clear that we can get long delays waiting for Direct2D to process
things on occasion. So given that we now detect when the reader has closed,
instead of guessing at a suitably long timeout, waiting indefintely while it
hasn't closed seems like a better option.
This gives a similar behaviour to when this is just running in the content
process, because that just has to wait on any long running Direct2D calls.
Differential Revision: https://phabricator.services.mozilla.com/D62464
--HG--
extra : moz-landing-system : lando
If the other side crashed with AboutToWait set in CanvasEventRingBuffer then in
theory we could spin forever waiting for it to change.
Differential Revision: https://phabricator.services.mozilla.com/D61828
--HG--
extra : moz-landing-system : lando
This sends a message to the content process on device reset/change. The content
process clears the CanvasImageCache and canvas TextureClients and then records a
new event, so the translator knows it has finished.
Differential Revision: https://phabricator.services.mozilla.com/D60890
--HG--
extra : moz-landing-system : lando
This is generally around object creation failures and their subsequent lookup,
which can happen, for example, during device reset.
Differential Revision: https://phabricator.services.mozilla.com/D60888
--HG--
extra : moz-landing-system : lando
We want to be able to send IPC messages from the translation in the parent. So
the simplest thing it move the top level actor parts of CanvasParent into
CanvasTranslator.
This patch also moves the canvas thread management parts out into a new
CanvasThreadHolder class and hopefully makes the lifecycle management of these
much more robust. This includes the use of a TaskQueue per CanvasTranslator to
manage serial processing on the canvas workers, instead of a boolean.
Differential Revision: https://phabricator.services.mozilla.com/D60887
--HG--
rename : gfx/layers/ipc/CanvasParent.cpp => gfx/layers/ipc/CanvasThread.cpp
rename : gfx/layers/ipc/CanvasParent.h => gfx/layers/ipc/CanvasThread.h
rename : gfx/layers/CanvasTranslator.cpp => gfx/layers/ipc/CanvasTranslator.cpp
rename : gfx/layers/CanvasTranslator.h => gfx/layers/ipc/CanvasTranslator.h
extra : moz-landing-system : lando
Move the UV writing function into the shared yuv.glsl include so
that the YUV compositing shader will be able to access it.
Differential Revision: https://phabricator.services.mozilla.com/D63815
--HG--
extra : moz-landing-system : lando
If only a single segment is produced, there is no benefit to writing
a segment instance array. Instead, just use the main primitive rect
written into the GPU cache.
Differential Revision: https://phabricator.services.mozilla.com/D63812
--HG--
extra : moz-landing-system : lando
Currently, the GetCMSOutputProfile() and related methods pass their output
using the old C-style "ptr, len" parameters. This makes them more difficult
to deal with later in this change when they need to be safely passed over IPC.
This refactors them to return nsTArray<uint8_t> results instead. I also
removed some old cruft and refactored the existing code.
Differential Revision: https://phabricator.services.mozilla.com/D63583
--HG--
extra : moz-landing-system : lando
The MOZ_LOG framework is the canonical Gecko logging framework, and provides
better control over what gets logged and where it goes, as well as provides
additional options like process/thread/timestamp prefixing of log output. This
patch does the minimum necessary to migrate the logs; each pre-existing
logging define is converted to a log module and all pre-existing log lines are
defaulted to LogLevel::Debug.
In addition, this prevents future breakage in the logging since everything
gets compiled on at least some configurations (e.g. non-Release, non-Android
builds).
Differential Revision: https://phabricator.services.mozilla.com/D63548
--HG--
extra : moz-landing-system : lando
Botond Ballo
Simon Giesecke
Martin Stransky
Andrew Osmond
Andreea Pavel
cbrewster
Dzmitry Malyshau
Miko Mynttinen
Daniel Varga
Jim Blandy
Dorel Luca
Jamie Nicol
Doug Thayer
Kartikaya Gupta
Cosmin Sabou
Nicolas Silva
Jonathan Kew
Sylvestre Ledru
Bogdan Tara
sotaro
Bob Owen
Glenn Watson
Greg V
Sean Feng
Chris Martin