In bug 1696905 I changed how clear tiles are rendered from multiply blend to opaque, however it breaks window controls on Windows 8 (the only thing that clear tiles are used for). This patch reverts clear tiles to the previous behavior.
I'm not sure how to test this part of the code because it depends on the widget integration code having something to show behind the window.
Differential Revision: https://phabricator.services.mozilla.com/D114327
This can make scene building up to 10% faster on some pages (such
as the youtube.com front page) that use a large number of clips.
Differential Revision: https://phabricator.services.mozilla.com/D114312
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
This was an old example / proof of concept of directly drawing
to a DirectComposition surface.
We now have the example-compositor/ project that shows how to
integrate with DirectComposition on Windows and Wayland on
Linux, in addition to a shipping implementation in Gecko for
CoreAnimation and DirectComposition.
Differential Revision: https://phabricator.services.mozilla.com/D113052
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
The original triangle winding check was designed to be run inside the span
rasterizer every time the edges changed. However, at present, this only ever
gets used once at the very top of the triangle to determine winding and then
assumes winding is constant thereafter.
This updates the check to work on these assumptions to be simpler and less
fragile where numerical precision is concerned. If we can assume the candidate
edges both start on the same row, then the check boils down to seeing if they
share the same starting point and doing a cross-product.
Differential Revision: https://phabricator.services.mozilla.com/D113900
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
The problem stems from the fact that to clip the dest rectangle to the source rectangle when there is
scaling between them, we have to round at each step due to the fact we're working in integer coordinates.
This causes us to nudge the coordinates in weird directions.
To avoid this, this uses a slightly different approach where we essentially modify the existing clip
rectangle functionality to factor in the texture bounds so that we don't have to do as many lossy
conversions.
Differential Revision: https://phabricator.services.mozilla.com/D112688
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
With the copying and scaling code in one place, it gets a bit hard to see in the profile which one
is being used. This just moves some of the dispatching between the two up a level so they show up as
different functions in a profile.
Differential Revision: https://phabricator.services.mozilla.com/D112613
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
Nicolas Silva
Glenn Watson
Jeff Muizelaar
Lee Salzman
Dorel Luca
Robert Mader
Miko Mynttinen
Alexandru Michis
Butkovits Atila
Jamie Nicol
imoraru
R. Martinho Fernandes
Sebastian Hengst
Brad Werth