When an offscreen surface establishes a raster root, this code
was causing incorrect snapping / rounded (even on non-inflated
surfaces), resulting in test failures in some cases.
In theory, this should not be necessary, since scroll offsets are
snapped, and primitives are already snapped during scene building.
Additionally, the picture surface allocation code expects surfaces
with fractional offsets and handles this case (by rounding out the
allocation size, and creating a UV set that samples from the subpixel
offsets of the surface).
In practice, there may be content that relies on this which isn't
tested by CI, so let's land this as a separate patch and see if it
causes any real-world content regressions, before landing the
changes that rely on this.
Differential Revision: https://phabricator.services.mozilla.com/D107768
When an offscreen surface establishes a raster root, this code
was causing incorrect snapping / rounded (even on non-inflated
surfaces), resulting in test failures in some cases.
In theory, this should not be necessary, since scroll offsets are
snapped, and primitives are already snapped during scene building.
Additionally, the picture surface allocation code expects surfaces
with fractional offsets and handles this case (by rounding out the
allocation size, and creating a UV set that samples from the subpixel
offsets of the surface).
In practice, there may be content that relies on this which isn't
tested by CI, so let's land this as a separate patch and see if it
causes any real-world content regressions, before landing the
changes that rely on this.
Differential Revision: https://phabricator.services.mozilla.com/D107768
BatchRects would like to avoid allocating and iterating over detailed rectangle
lists when the bounding box is not much larger than the area of the detailed
rectangle lists, such that the approximation won't affect the accuracy of
intersection queries. But bounding boxes can badly overestimate intersections,
so sometimes a detailed list must be retained.
Thus, the heuristic in `add_rect` should start a detailed rectangle list when
the area of the old BB and the new rectangle is *less* than that of the new BB,
not more.
Differential Revision: https://phabricator.services.mozilla.com/D107696
In the spirit of keeping primitive-specific logic mostly in the same place, this moves the linear gradient render task and the code to convert it into a gpu-visible instance into linear.rs.
I'm planning to give all specific render task structures/logic the same treatment eventually.
Differential Revision: https://phabricator.services.mozilla.com/D107676
Historically WebRender's code has used 'gradient' as a shorthand for 'linear gradient' and often more specifically for 'the fast path for linear gradients'. This patch makes the naming less ambiguous in particular in places where we'll see more types of gradients sid by side introduced by upcoming patches in this series.
Differential Revision: https://phabricator.services.mozilla.com/D107642
prim_store/gradient.rs is large enough that splitting it up will make things a bit clearer. The new organization is:
- prim_store/gradient/mod.rs: shared/gradient-agnostic code.
- prim_store/gradient/<linear|radial|conic>.rs: specific gradient code.
In addition, various gradient-specific data structures currently living in other modules will move into the proper gradient modules as part of this patch series.
For convenience, all specific public symbols are reexported in prim_store::gradient.
Differential Revision: https://phabricator.services.mozilla.com/D107641
It is the cs_* shader used to cache linear gradients in the simple/fast path (more complex linear gradients are rendered with a brush shader. The goal of this patch series is to move all gradients to cached render tasks that will be composited with brush_image, so there will be a cs_linear_gradient introduced in a followup to cover the general case as well as cs_radial_gradient and cs_conic_gradient to replace the brush equivalents.
Differential Revision: https://phabricator.services.mozilla.com/D107640
glslopt error messages typically look like:
314(15): error: syntax error, unexpected NEW_IDENTIFIER, expecting ',' or ';'
Which would be fine if we had a way to see what is at line 314, however we don't store the concatenated shader string on disk so it's a bit hard to guess where in the source a typo led to a an unknown identifier.
This patch makes the build script print the shader source with line numbers when glslopt throws an error.
Differential Revision: https://phabricator.services.mozilla.com/D107655
Add MixBlend and ComponentTransfer to the picture composite modes that
unconditionally establish a raster root.
All the known bugs with the raster root code have been fixed, so let's
start incrementally enabling raster roots for more picture modes, and
fix any regressions that come from these before making raster roots
the default for all surfaces.
Differential Revision: https://phabricator.services.mozilla.com/D107405
This fixes a bug wherein we were calculating the distance to the corner apex incorrectly
which could result in it being clipped in the presence of transforms that cause the step
scale to not be axis-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D107618
It is possible to support 24-bit depth in SWGL without a large performance hit
and without increasing the size of the depth buffer. Since depth runs already
have 32-bit entries, if we carefully limit the depth run size to 8 bits we have
24 bits left over to store the actual depth value.
Differential Revision: https://phabricator.services.mozilla.com/D107409
During the frame graph refactoring, a new Pass type was introduced which holds the render task ids for a given pass (before we attribute the task ids to sepcific sub-passes of RenderPass). As a result, the tasks vector of RenderPass which the SVG dumps reads is now unused and always empty.
This patch removes the unused tasks vector and fix the svg dump so that it reads from the Pass struct instead.
Differential Revision: https://phabricator.services.mozilla.com/D106945
The check for which tiles of a clip mask need to be drawn was using
the surface device pixel ratio to calculate a true device position
for the tile. In most cases, this works fine.
However if the device pixel ratio of a surface is different to the
global device pixel ratio (e.g. due to a scale factor being applied
on a surface that establishes a raster root), then the calculations
are incorrect and can result in skipping clip mask tiles that do
need to be rendered for correctness.
Differential Revision: https://phabricator.services.mozilla.com/D107167
Since WebRender doesn't need texture array support anymore, neither does SWGL.
This is a massive simplification which should benefit both performance and
simplicity. This patch pretty much just removes functionality but doesn't
change any functionality that is already used and relied upon.
Differential Revision: https://phabricator.services.mozilla.com/D106718
Fix a bug that can occur when:
- Parent stacking context is considered redundant
- Parent stacking context has a transform
- Parent stacking context establishes a raster root
- Parent stacking context has a clip
- Child stacking context has a filter (or other feature requiring a surface)
In these cases, the clips would be incorrectly propagated to the
primitives inside the child stacking context, instead of applied
to the child stacking context surface itself. This can cause correctness
issues when raster roots are established, and potential performance
issues if raster roots are not established.
Differential Revision: https://phabricator.services.mozilla.com/D107024
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
Add an explicit match on picture composite mode, forcing tile caches
to never be raster roots, and add a test that fails if a tile cache
is marked as a raster root.
Follow ups to this patch will incrementally move more composite modes
to be raster roots, allowing us to fix up any regressions without
switching everything to be a raster root at once.
Differential Revision: https://phabricator.services.mozilla.com/D106859
Add an explicit match on picture composite mode, forcing tile caches
to never be raster roots, and add a test that fails if a tile cache
is marked as a raster root.
Follow ups to this patch will incrementally move more composite modes
to be raster roots, allowing us to fix up any regressions without
switching everything to be a raster root at once.
Differential Revision: https://phabricator.services.mozilla.com/D106859
Conceptually we should only sample APZ on frame build, never on scene
build. When a late scene build occured, this unnecessary sample was
the underlying cause of the non-monotonic sample times as seen in bug
1653796. The fix for bug 1653796 introduced non-vsync-aligned sample
times to work around this, but these lead to inconsistent scroll
deltas during fling animations, appearing as janky scrolling on
Android.
This patch fixes the underling issue, by removing the sample after
scene building. This means we no longer hit the case where sample
times are in the past after a late scene build, allowing us to revert
bug 1653796 to ensure that sample times remain vsync-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D106414
The calculation of the available backdrop rect was incorrect in the
case of a picture cache slice that is both scrolled and also clipped
by long content which is affected by the mix-blend-mode.
Differential Revision: https://phabricator.services.mozilla.com/D106572
cs_clip_rectangle is slow because we evaluate distance AA for every fragment
the shader touches. With SWGL, we can do much better since we have control
over span. We calculate an inner opaque octagon which can just use a cheap
solid fill and an outer AA octagon within which we need to actually we do
AA and outside which we can just do another solid clear. This reduces most
of the cost of rounded-rectangles to just some setup work, a few fragments
of distance AA on the ends of a span, and large runs of solid color where
we don't have to do much work.
Differential Revision: https://phabricator.services.mozilla.com/D106658
Also rename the shader's ImageResource into ImageSource to match the terminology on the rust side (especially since the rust code has a different thing named ImageResource).
Differential Revision: https://phabricator.services.mozilla.com/D106484