Currently when selecting the scroll root for picture caching, if a
non-Zoom transform is encountered we give up and select the root
spatial node. This is because the transform may be non-axis aligned.
When the Fenix dynamic toolbar is enabled, fixed position items must
create a spatial node with an animated transform, so that they can be
positioned asynchronously by APZ when the toolbar moves.
The combination of these two things means for that scroll frames
within fixed position items we always select the root spatial node,
meaning that the entire contents invalidates continuously while
scrolling.
To fix this, add a flag to the Transform ReferenceFrameKind which
marks the transform as always being a 2D scale or translation. When
selecting the scroll root, we can continue searching through such
reference frames, as we already do for Zoom frames. Set this flag true
for references frames created due to the dynamic toolbar.
Additionally, assert that the transform is indeed a 2d scale or
translation after it is resolved.
The condition of the transform being only a 2d scale and translation
is shared with ReferenceFrameKind::Zoom, so that has been removed and
its uses updated to use this new flag instead. An additional
should_snap flag has also been added, so that we continue to snap zoom
transforms, and additionally snap the dynamic-toolbar related
transforms too.
Lastly, this adds some unit tests for find_scroll_root.
Differential Revision: https://phabricator.services.mozilla.com/D106809
It's always supplied by Gecko anyway, and being able to rely on this
will make it easier to create stable spatial node IDs that persist
across display lists.
Differential Revision: https://phabricator.services.mozilla.com/D100076
This ID allows the compositor to track per-frame information from frame
generation, through APZ sampling, to the NotifyDidRender notification.
Differential Revision: https://phabricator.services.mozilla.com/D97535
In the following circumstances, WR was failing to detect a
composite was required:
- There is a picture cache slice that is smaller than a single tile.
- The position of that picture cache slice is changed.
- No other content invalidations occur.
This clip rect in the composite descriptor must include the
device_valid_rect rather than the tile device_rect. This ensures
that in the case of a picture cache slice that is smaller than a
single tile, the clip rect in the composite descriptor will change
if the position of that slice is changed. Otherwise, WR may conclude
that no composite is needed if the tile itself was not invalidated
due to changing content.
Differential Revision: https://phabricator.services.mozilla.com/D96966
This removes some of the complexity in the renderer associated with
drawing multiple document layers in a single render. It retains
the rest of the document API, which will be used to implement the
functionality in bug #1654938.
Differential Revision: https://phabricator.services.mozilla.com/D95478
This patch removes the public API and high level logic for
disabling picture caching for debugging and pinch-zoom in
some cases.
Follow up patches will remove and simplify the internal parts
of WR that remain to handle the disabled picture caching
code path.
Differential Revision: https://phabricator.services.mozilla.com/D93446
Previously we used a single texture array for a given tile size,
and resized the texture array as more tiles were needed.
However, this results in expensive driver stalls and GPU copy times
when resizing the array.
Instead, use a fixed slice count for each texture array, and support
multiple textures with the same tile size.
This may result in slightly more draw calls during compositing of
picture cache tiles due to batch breaks, but will remain a small
number due to the limited number of picture cache tiles that are
allocated at any one time.
Differential Revision: https://phabricator.services.mozilla.com/D92715
Previously, the content_size was used when defining an iframe
to set the size of the root scrollable area.
However, this was never useful (the root pipeline scroll frame
is not considered a scroll root, it's more of a placeholder).
The scroll frame for content is typically defined within the
iframe display list (which also allows non-scrolled content
within the iframe, such as a background rectangle color).
The existing content_size was causing problems in Gecko because
there are some snapping / rounding inaccuracies with fractional
DPI ratios, resulting in root scroll frames with +/- 1 pixel
scrollable size.
The simplest fix for this is to remove content_size altogether
and rely on the iframe display item to define the content size
of the root scroll frame for a pipeline.
Differential Revision: https://phabricator.services.mozilla.com/D85719
They aren't used, so can easily be removed as the first part of
this seried of patches.
If this functionality is ever required, it can be handled by the
caller defining complex clip nodes explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D72261
This is not used, so we can remove it as the first part of modifying
the public clip API in order to allow some internal optimizations.
If callers ever want to make use of this in future, it can be
achieved by placing an image mask clip node in the clip chain for
the primitives in the scroll layer.
Differential Revision: https://phabricator.services.mozilla.com/D72099
This should remove the allocation and copy in
TextureD3D::ensureRenderTarget() in some situations.
Differential Revision: https://phabricator.services.mozilla.com/D62952
--HG--
extra : moz-landing-system : lando
This should remove the allocation and copy in
TextureD3D::ensureRenderTarget() in some situations.
Differential Revision: https://phabricator.services.mozilla.com/D62952
--HG--
extra : moz-landing-system : lando
Adds an #ifdef to the DCLayerTree implementation that allows
selecting whether to use the virtual surface API (enabled by
default) or the regular DC surface API.
For now, this is a compile-time switch. As a follow up to this,
we will support both options at runtime (for example, using the
regular surface API for surfaces that have holes or translucency).
Differential Revision: https://phabricator.services.mozilla.com/D58870
--HG--
extra : moz-landing-system : lando
This will allow use of the DirectComposition virtual surface API. If
it turns out that some pages recreate surfaces a lot due to opacity
changing, we can add some extra logic to avoid recreating surfaces
as often, and making use of per-tile opacity in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D57592
--HG--
extra : moz-landing-system : lando
Adds more picture cache slices to the example application, and makes
the visual tree layer update match the strategy that Gecko uses.
Differential Revision: https://phabricator.services.mozilla.com/D54452
--HG--
extra : moz-landing-system : lando
Update the example compositor implementation to use the faster
EGLImage technique that the Gecko implementation now uses.
Differential Revision: https://phabricator.services.mozilla.com/D54185
--HG--
extra : moz-landing-system : lando
Update the example compositor implementation to use the faster
EGLImage technique that the Gecko implementation now uses.
Differential Revision: https://phabricator.services.mozilla.com/D54185
--HG--
extra : moz-landing-system : lando
This passes the existing dirty rect for a picture cache update
through the native compositor interface, allowing compositors
to only update a sub-rect of a tile.
Also update the example to pass dirty rect to DirectComposition,
and add debug drawing for compositor redraw region.
Differential Revision: https://phabricator.services.mozilla.com/D50767
--HG--
extra : moz-landing-system : lando
Platform differences between DirectComposition and CoreAnimation
mean that WR needs to bind the FBO ID that the underlying platform
returns as part of the surface binding operation.
Differential Revision: https://phabricator.services.mozilla.com/D50760
--HG--
extra : moz-landing-system : lando
This patch is a small refactor of the public and internal structures
for options related to partial present and native compositing. It
doesn't contain any functional changes.
It adds a field to the native compositing setup to allow clients to
express whether dirty rect updates are supported when native compositing
is enabled (not currently used but will be enabled soon).
It also removes the partial present config options, and makes them
part of the default / draw compositing mode.
Differential Revision: https://phabricator.services.mozilla.com/D50521
--HG--
extra : moz-landing-system : lando
Jamie Nicol
Robert Mader
sotaro
Markus Stange
Glenn Watson
Jeff Muizelaar
Coroiu Cristina
Glenn Watson
Lee Salzman
shindli
Jeff Muizelaar
Arthur Iakab
Daniel Varga
Razvan Maries