This patch adds support for YUV images to be promoted to compositor
surfaces when using the simple (draw) compositor mode. A follow up
to this will extend support to native compositor implementations.
We rely on only promoting compositor surfaces that are opaque
primitives. With this assumption, the tile(s) that intersect the
compositor surface get a 'cutout' in the location where the
compositor surface exists, allowing that tile to be drawn as
an overlay after the compositor surface.
Tiles are only drawn in overlay mode if there is content that
exists on top of the compositor surface. Otherwise, we can draw
the tiles in the normal fast path before the compositor surface
is drawn.
The patch also introduces a new subpixel AA mode, which allows
subpixel rendering to be enabled conditionally as long as the
text run does not intersect some number of excluded rectangle
regions. In this way, subpixel text remains on most of the page,
but is disabled for elements that are drawn into transparent
regions of the tile where the compositor surface exists.
This allows video playback to be composited directly into the
framebuffer, without invalidation of content tiles, which can
save a significant amount of battery power and improve performance.
Differential Revision: https://phabricator.services.mozilla.com/D63816
--HG--
extra : moz-landing-system : lando
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
Bogdan Tara
Hiroyuki Ikezoe
Cosmin Sabou
Kartikaya Gupta
Glenn Watson
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
Nicolas Silva
Jonathan Kew
Sylvestre Ledru
sotaro
Bob Owen