Previously, primitive sub-dependencies (such as transforms, opacity
bindings etc) were invalidated by comparing the dependency array
only. This means that it's not possible to correlate an area of
a tile that is affected by those sub-dependencies.
Now, comparisons on sub-dependencies are handled as part of the
dependency check for each primitive. This means we have the
affected rectangle of the tile available, which will allow
dirty regions within a tile to be built correctly.
This patch is only preparation work - the actual dirty rect
calculation will be done as a follow up patch.
Differential Revision: https://phabricator.services.mozilla.com/D44771
--HG--
extra : moz-landing-system : lando
Previously, picture caching code would use the viewport of the
scroll root to find a clipping rect for picture cache tiles. This
viewport rect was also used to eliminate fixed position clip rects
on primitives that would otherwise cause unwanted invalidations
due to them moving relative to the scroll root when scrolls occur.
Now, the picture caching code uses a similar technique to Gecko
to find shared clips on primitives in a picture cache. These clips
are filtered out from being applied on a per-primitive basis, and
instead applied once during compositing the tiles into the parent
picture.
This is a potential performance improvement, since less per-item
work is required when building clip chains. More importantly, it
means the picture caching code correctly handles cases where the
scroll root contains fixed position elements (or other scroll
roots). This is a requirement before we can enable picture caching
on multiple slices.
Differential Revision: https://phabricator.services.mozilla.com/D44618
--HG--
extra : moz-landing-system : lando
Previously, clip nodes interned the local clip information, but
stored the spatial node and the local position as part of the
instance.
This was required since the local position of clips would change
when a new display was sent after scrolling. However, since we
now handle this via external scroll offsets, the local position
is stable, and we can intern both the position and spatial node.
This greatly simplifies some in-progress work for picture caching,
where we want to be able to quickly identify clip chain nodes that
are shared between elements of a display list. With this change,
comparing the item uid of the interned clip node is enough to
guarantee equality of the shared clips.
Differential Revision: https://phabricator.services.mozilla.com/D44436
--HG--
extra : moz-landing-system : lando
Previously, additional dependencies (such as opacity bindings and
transforms) were stored in a simple hash set, which meant they
could not be correlated with primitive bounding rects (and thus
could not be used to derive dirty rects of a tile).
Now, by scanning the primitive list which contains the bounding
rect, we can also find additional dependencies for that primitive.
This will be used in future to create exact dirty rects (for
debugging / regression testing) and allow us to generate a
dependency descriptor for a split or merged tile from an existing
descriptor.
This patch also fixes a case where opacity bindings could result
in unnecessary invalidations, by retaining the opacity bindings
state across display lists.
Differential Revision: https://phabricator.services.mozilla.com/D42473
--HG--
extra : moz-landing-system : lando
Since the filtered-backdrop is 1:1 with the backdrop, we don't want any snap offsets to shift the contents
Differential Revision: https://phabricator.services.mozilla.com/D42042
--HG--
extra : moz-landing-system : lando
Fixes an issue when backdrop-filter is used many time on a page where we would
spend a large amount of time reevaluating render tasks when assigning task depths.
Differential Revision: https://phabricator.services.mozilla.com/D41252
--HG--
extra : moz-landing-system : lando
With this patch, tiles that are covered only by the opaque backdrop
primitive are detected and noted as solid colors.
Solid color tiles save memory and performance, because:
- No texture slice is allocated as a render target for them.
- No need to rasterize this tile.
- Drawing the tile is done with the faster rectangle shader.
This already saves performance and GPU memory on quite a few
real world sites (esp. when running at 4k). However, the main
benefit of this will be once we enable picture caching on
multiple content slices and the UI layer. When this occurs, it's
important to avoid allocating tile buffers for all the solid
rectangle tiles that the UI layer typically contains.
Differential Revision: https://phabricator.services.mozilla.com/D41342
--HG--
extra : moz-landing-system : lando
Frames captured by the composition recorder on non-ANGLE configurations were
previously written upside down to disk. We now flip them right side up when
mapping them into memory.
Differential Revision: https://phabricator.services.mozilla.com/D40113
--HG--
extra : moz-landing-system : lando
This is a medium-size follow-up to D21965.
Refactors the use of swizzling by the texture cache. Adds a device
capability flag that is checked at run-time. Also makes the texture
cache to communicate with the texture uploader if there is a format
conversion needed, which fixes the case on platforms that don't
support swizzling.
Differential Revision: https://phabricator.services.mozilla.com/D41446
--HG--
extra : moz-landing-system : lando
When adding planes to the plane splitter, we supply a world clip
rect to the polygon clipper. Generally this is used to help with
float accuracy issues, but it also clips polygons to the visible
region.
The previous code supplied the visible world rect, but this is
not always correct. When drawing picture cache tiles, we may
be rendering to a tile that is partially off-screen. In this case
we need to pass the combined world dirty rect, which is inflated
to include the off-screen tile parts that are being drawn. This
ensures that preserve-3d items are correctly clipped to the tile
boundaries rather than the currently visible screen rect.
Differential Revision: https://phabricator.services.mozilla.com/D41111
--HG--
extra : moz-landing-system : lando
have texture cache to manage potentially multiple array textures of each type.
Differential Revision: https://phabricator.services.mozilla.com/D39912
--HG--
extra : moz-landing-system : lando
those unwrap_or are mostly seen during the batching, where we should asssume that
the primitives are not clipped out and just unwrap() accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D39940
--HG--
extra : moz-landing-system : lando
Refactors get_clip_result_complex to cover ClipOut cases for rectangles as well
as Clip for non-repeated images.
Differential Revision: https://phabricator.services.mozilla.com/D40094
--HG--
extra : moz-landing-system : lando
Allow the swizzle to be configurable with a texture binding. This is still experimental and needs to be tested well on all platforms.
Basic approach is the following:
- WR device figures out how it can use BGRA and makes the texture cache format configurable at run-time. It tries to make the uploads to the shared texture cache pages to be done without any driver conversions, and without extra memory allocated.
- it also reports the preferred input format for the images, which may be different from the texture cache format
- if WR texture cache is asked to allocate a shared texture with a different (swizzled) format from the preferred, it associates the cache entry with a swizzle
- the swizzle becomes a part of the `SourceTexture`, which affects batch splitting
- when a texture reaches binding by GL device, it checks whether the current swizzle on this texture doesn't match the given one, and configures the texture sampling accordingly
- we can't use blits with swizzling, so when that needs to happen we use `cs_copy` path, which is now mostly rewritten
The idea is that Gecko would ask WR for the preferred format and configure its image decoding to produce image data that doesn't require any swizzling.
The PR changes existing texture upload (and batching) paths. On Linux, if texture storage is available, we now use it and provide the data as RGBA, assuming no conversion by the driver. The swizzling kicks in when we sample this data in the shader. On Windows/Angle we use BGRA as an internal format for texture cache and expect Gecko to provide BGRA data, this should be unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D21965
--HG--
extra : moz-landing-system : lando
The glReadPixels call for capturing profiler screenshots is very slow
on Adreno devices. Similarly to bug 1498732, this is because the
stride of the data being transferred is not a multiple of 256, so the
driver is taking the synchronous path instead of reading in to a PBO
asynchronously.
This solves this problem by increasing the width of the area we read
so that we hit the fast path. To do this we must ensure that the PBO
and the final scale-down texture are large enough to include the extra
pixels in each row. As the required size of the PBO or texture may now
change, for example after a screen rotation, we now handle deleting
and recreating them when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D39189
--HG--
extra : moz-landing-system : lando
looks like a typo that got unnoticed? I wonder how our alpha saved tasks work today :)
Differential Revision: https://phabricator.services.mozilla.com/D39021
--HG--
extra : moz-landing-system : lando
This patch fixes a couple of picture caching issues that could
cause more invalidations than required. Specifically:
* Ensure the viewport rect is included in child surfaces, so
that redundant clips are filtered out correctly.
* Use epsilon comparisons where appropriate for tile descriptor
comparisons, to avoid invalidations due to float inaccuracies.
Differential Revision: https://phabricator.services.mozilla.com/D38455
--HG--
extra : moz-landing-system : lando
The code to batch preserve-3d elements was incorrectly using the
bounds and visibility mask from the parent element. This could
result in batching bugs in some cases, which were showing up as
draw order issues.
Differential Revision: https://phabricator.services.mozilla.com/D38834
--HG--
extra : moz-landing-system : lando
This patch reverts the previous attempted fix for snapping issues
with picture caching, and implements a better solution.
This fixes the main visual issue by ensuring that any fractional
offset in the root transform is accounted for by:
* Offsetting the tile rects by this amount, so that the content
origin is a whole device pixel.
* Invalidating all tiles if the fractional part of the root
transform changes. This is required since it can affect the
snapping logic that WR applies. Fortunately, this occurs
very rarely - Gecko typically has a constant fractional part
for each page.
Differential Revision: https://phabricator.services.mozilla.com/D38267
--HG--
extra : moz-landing-system : lando
This patch reverts the previous attempted fix for snapping issues
with picture caching, and implements a better solution.
This fixes the main visual issue by ensuring that any fractional
offset in the root transform is accounted for by:
* Offsetting the tile rects by this amount, so that the content
origin is a whole device pixel.
* Invalidating all tiles if the fractional part of the root
transform changes. This is required since it can affect the
snapping logic that WR applies. Fortunately, this occurs
very rarely - Gecko typically has a constant fractional part
for each page.
Differential Revision: https://phabricator.services.mozilla.com/D38267
--HG--
extra : moz-landing-system : lando
When rendering text in webrender we rasterize glyphs either in local
space at a chosen raster scale, or in device space taking in to
account to text's transform.
We are not able to rasterize glyphs larger than a certain size,
however. So if the device-space font size exceeds this limit, then
currently we force the glyph to be rasterized in local space, at the
untransformed font size. This must then be scaled by the shader when
rendering text, and at high zoom levels this will result in blurry
text.
This change makes it so that rather than rasterizing at the
untransformed font size we rasterize at the font size limit. This will
mean the glyphs are rasterized at a larger size and will therefore
require less scaling, meaning they will appear less blurry.
Differential Revision: https://phabricator.services.mozilla.com/D37644
--HG--
extra : moz-landing-system : lando
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
--HG--
extra : moz-landing-system : lando
