It used to be more convenient to store them in separate arrays but with the new occlusion culling code we don't benefit from it and have to undo it to traverse tiles from front to back.
This is a cleanup patch that should not change the behavior of the code.
Differential Revision: https://phabricator.services.mozilla.com/D113989
This patch introduces a simple culling algorithm that splits compositor tiles into only their visible parts, removing the need for a depth buffer. This reduces the draw-call count as well well as the memory usage and bandwidth associated with the depth buffer.
Differential Revision: https://phabricator.services.mozilla.com/D113532
If an iframe has complex clips, we need to skip including them
in the iframe specific clip applied to the tile cache, as that
path only supports rectangle clips.
Differential Revision: https://phabricator.services.mozilla.com/D114190
If we optimize a root level blend container to be a tile cache, we
need to ensure we don't promote compositor surfaces within this slice
as it can result in incorrect blending.
Differential Revision: https://phabricator.services.mozilla.com/D114176
WebRender internally reverses gradient stops when they are ordered from right to left. This is done while building the GPU data and the gradient cache key stored the reversed stops without sepcifying if they were revered or originally in that order. This meant that if a page had two similar gradients with the only difference being that on was reversed but not the other, they could end up using the same cache key and one of the two would not be rendered properly.
This patch includes a boolean in the cache key to make sure reversed gradients don't accidentally use the same key as similar non-reversed gradients.
Differential Revision: https://phabricator.services.mozilla.com/D113975
Large segment bounds trip an assertion when casting coordinates to integers. Clipping early also reduces the amount of cached pixels.
Differential Revision: https://phabricator.services.mozilla.com/D113819
Large gradients are cached scaled down and stretched back by the image brush. Because the scaling factor is non-uniform the shader has to take it into account. The previous implementation was incorrectly accounting for the scale.
Differential Revision: https://phabricator.services.mozilla.com/D113753
Rather than have SwCompositor or the individual RenderCompositors track this, it seems easier
to just have WR itself avoid calling add_surface or start_compositing if we're inside an update.
Differential Revision: https://phabricator.services.mozilla.com/D113953
Large gradients are cached scaled down and stretched back by the image brush. Because the scaling factor is non-uniform the shader has to take it into account. The previous implementation was incorrectly accounting for the scale.
Differential Revision: https://phabricator.services.mozilla.com/D113753
We were already clipping off most of the AA inside cs_clip_image previously anyway.
Given that it is too unpredictable in what situations the little bit of remaining
AA was actually applying, and that it causes visual artifacts sometimes when it
activates where it shouldn't, we're better off just using a rough clip inside this
shader for everything so that it is always predictable.
Differential Revision: https://phabricator.services.mozilla.com/D113545
The code that decompose linear gradients inserts fake gradient stops to deal with the potential constant color areas before and after the gradient endpoints. The offsets of these extra stops were computed without accounting for the transformation the loop does in the case of reversed stops. This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D113290
Recent changes in cs_clip_image are exposing some cases where we are letting rectangles being warped
by perspective transform get considered as axis-aligned. This makes the axis-alignment check stronger
for clipping to guard against the Z dependency in the W coordinate that is messing up clipping.
Differential Revision: https://phabricator.services.mozilla.com/D113259
Using native compositor integration should imply the y-flip can be
done by the system compositor - this is true for CA, DC and Wayland.
As the Wayland backend now does so, remove the
surface_origin_is_top_left support again, making sure
the Wayland backend uses the same code paths as CA/DC backends do.
Note:
- In order to not regress bug 1680128, do not revert the override
of `SurfaceOriginIsTopLeft()` in `RenderCompositorNative.h`
- Explicitely set `surface_origin_is_top_left: false` in the example
compositor. This is the default, however setting it explicitely
would have helped me bring up the Wayland example compositor.
This is purely a hint for potential future backends.
Differential Revision: https://phabricator.services.mozilla.com/D113217
It's possible that the overall clip transform isn't axis-aligned even if the primitive transform is. So we rather
need to verify that this overall transform is axis-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D113188
This patch breaks linear gradients into two primitives:
- LinearGradient is always rendered via the brush shader. It is only used with SWGL.
- CachedLinearGradient is always rendered via a cached render task and the brush image shader. Its implementation is very similar to conic and radial gradients, with the addition of a fast-path for axis aligned gradients with two stops.
In addition the following changes are made:
- The gradient fast path is simpler (only deals with two gradient stops).
- Decomposing axis-aligned gradients into parts eligible for the fast path happens during scene building instead of frame building.
Differential Revision: https://phabricator.services.mozilla.com/D112018
This forces current_job to null as soon as it is known whether there are no more
bands available so that current_job is always null if job_count is zero.
Differential Revision: https://phabricator.services.mozilla.com/D112891
This was required to workaround a driver bug on Adreno devices when
blitting to texture arrays. It is no longer required as we have
stopped using texture arrays, due to all the driver bugs.
It's currently just dead code as we stopped initializing the buffers
when we removed texture array support. This patch just removes the
dead code.
Differential Revision: https://phabricator.services.mozilla.com/D112697
In bug 1630356 we found a driver bug on some Adreno 3xx devices where
flat scalar varyings in shaders incorrectly caused the output of every
fragment in the triangle to be calculated as if flat. To work around
the bug, we pack the scalar varyings in a vector. At the time we
believed it may be limited to varyings used to calculate UV
coordinates, however, we have now seen more cases of this bug (in box
shadows, gradients, and svg filters).
Unfortunately it is not yet clear what precise conditions are required
to trigger this bug, so for now we just apply the workaround to the
varyings we know are affected due to failing wrench tests on the device.
Differential Revision: https://phabricator.services.mozilla.com/D112334
We don't currently handle the case where a compositor surface is inside a
picture primitive that is a pass through (has composite mode of None),
because we only count required compositor surfaces at the top level prim
list of a tile cache.
However, the code to promote a surface was only checking if it existed on
the same physical surface, not the root picture cache.
This patch prevents compositor surfaces being promoted in this case (which
only occurs if inside a backdrop-filter container, or a 3d transform root).
Differential Revision: https://phabricator.services.mozilla.com/D112153
This performs a winding number calculation on the polygon and matches the
result against the fill rule of the supplied polygon.
Differential Revision: https://phabricator.services.mozilla.com/D109946
This patch defines a SetPoints DisplayItem for providing polygon mask points
associated with a ImageMaskClipDisplayItem. It also defines a WR enum for the
polygon fill rule. The method to provide these values to WR is mere scaffolding
until later patches in this series.
Differential Revision: https://phabricator.services.mozilla.com/D105396
The variable supports_texture_storage during webrender device
initialization has 2 different meanings depending on whether we are
running GL or GLES. For GL, it indeed indicates whether glTexStorage
is supported. For GLES, however, it indicates whether the extension
GL_EXT_texture_storage is supported.
In GLES 3, glTexStorage is always supported for most formats. The
relevance of whether the GL_EXT_texture_storage extension is supported
is that it means glTexStorage can be used with GL_BGRA8. (This is
because the GL_EXT_texture_format_BGRA8888 extension was written
against GLES 2 + GL_EXT_texture_storage, and has never been updated
for GLES 3.)
This is why in the GL case we must check supports_texture_storage
before allowing texture storage usage, but in the GLES case we do not
bother checking, except for when using BGRA. This is confusing.
To make this less confusing, this patch checks directly for the
extension support in the GLES + BGRA case. We do not bother checking
the value of supports_texture_storage in any non-BGRA GLES cases, as
it is always true and would only further complicate logic that is
already too complex. If this is required in the future (eg to work
around a buggy glTexStorage implementation) we can always add it then.
Differential Revision: https://phabricator.services.mozilla.com/D112172
On Adreno 3xx we see intermittently corrupted or missing glyphs due to
texture uploads failing. This has only started occuring since glyphs
were switched to using R8 format textures, from RGBA8.
Due to performance reasons on other Adreno devices, we currently
ensure texture data has a stride aligned to 64 pixels. So the effect
of switching texture format is that the alignment switched from 256
bytes to 64 bytes.
It appears that PBO texture uploads must be performed with an
alignment of 128 bytes on Adreno 3xx, otherwise this corruption may
occur. Additionally, the 64 pixel requirement to hit the fast path
does not seem to apply to Adreno 3xx. Therefore this patch sets the
requirement to 128 bytes on Adreno 3xx, and leaves it as 64 pixels on
other Adreno devices.
It also renames optimal_pbo_stride to required_pbo_stride, to better
reflect the fact that this is now sometimes required for correctness
reasons, not just performance.
Differential Revision: https://phabricator.services.mozilla.com/D112058
Running webrender on PowerVR Rogue devices results in some images
being rendered with swapped R and B channels. This is because we use
texture swizzling for images in the shared texture cache, and
presumably the driver has a buggy implementation. This patch disables
texture swizzling on all PowerVR Rogue devices as a precaution.
It also ensures that we always use BGRA format textures in cases where
texture swizzling is unsupported, otherwise we encounter GL errors
when attempting to upload BGRA data to RGBA format textures, as GLES
does not support format conversion during upload. Furthermore, we make
it so that using RGBA+glTexStorage+swizzling is preferred to
BGRA+glTexImage in cases where swizzling is actually supported, as we
generally want to prefer glTexStorage to glTexImage.
Lastly, in cases where neither BGRA or swizzling are supported, rather
than attempting to upload BGRA data to RGBA textures (which will
result in a GL error) we pretend the BGRA data is RGBA. This will
result in the channels being swapped when rendering, but that is
preferable to the alternative of images not being uploaded at
all. This configuration shouldn't actually exist in the wild anyway.
Differential Revision: https://phabricator.services.mozilla.com/D111840
This performs a winding number calculation on the polygon and matches the
result against the fill rule of the supplied polygon.
Differential Revision: https://phabricator.services.mozilla.com/D109946
This patch defines a SetPoints DisplayItem for providing polygon mask points
associated with a ImageMaskClipDisplayItem. It also defines a WR enum for the
polygon fill rule. The method to provide these values to WR is mere scaffolding
until later patches in this series.
Differential Revision: https://phabricator.services.mozilla.com/D105396
This patch enables the sub-slice support landed in previous
patches, to allow non-opaque external images to be treated as
native compositor surfaces.
Each picture cache has one or more sub-slices, which form the
tile grid of picture cache targets. Sub-slices are added as
required based on the number of compositor surfaces that are
found during scene building.
As primitives are added to the picture cache dependencies, the
appropriate sub-slice to add the primitive to is calculated. This
depends on whether the primitive intersects any of the compositor
surface rects (and thus must be drawn after that surface). Prims
are added to the earliest sub-slice possible, to maximize the
chance that the primitive is on the primary sub-slice. This means
the prim can be rendered with subpixel AA due to an opaque background
in most cases, and also reduces the number of alpha tiles that are
allocated and must be composited.
Creating extra sub-slices and tile grids is relatively cheap - the
backing surface for a tile is only allocated once there are prims
in that tile to draw. The valid rect tracked for each tile also
ensures that a minimum rect is used during drawing and compositing.
Differential Revision: https://phabricator.services.mozilla.com/D111967
This patch enables the sub-slice support landed in previous
patches, to allow non-opaque external images to be treated as
native compositor surfaces.
Each picture cache has one or more sub-slices, which form the
tile grid of picture cache targets. Sub-slices are added as
required based on the number of compositor surfaces that are
found during scene building.
As primitives are added to the picture cache dependencies, the
appropriate sub-slice to add the primitive to is calculated. This
depends on whether the primitive intersects any of the compositor
surface rects (and thus must be drawn after that surface). Prims
are added to the earliest sub-slice possible, to maximize the
chance that the primitive is on the primary sub-slice. This means
the prim can be rendered with subpixel AA due to an opaque background
in most cases, and also reduces the number of alpha tiles that are
allocated and must be composited.
Creating extra sub-slices and tile grids is relatively cheap - the
backing surface for a tile is only allocated once there are prims
in that tile to draw. The valid rect tracked for each tile also
ensures that a minimum rect is used during drawing and compositing.
Differential Revision: https://phabricator.services.mozilla.com/D111967
Nicolas Silva
Glenn Watson
Jeff Muizelaar
Lee Salzman
Dorel Luca
Robert Mader
Miko Mynttinen
Alexandru Michis
Butkovits Atila
Jamie Nicol
Sebastian Hengst
Brad Werth
smolnar