This test tests that shadows that are offset to outside the clip region
but where the blur goes back into the clip region get correctly drawn
and not optimized away.
To view what the test actually draws, remove at least the color-matrix
- it's only used so the blurring algorithm doesn't cause different
results - and maybe also the clip node.
The test existed in git but wasn't hooked up. So let's do that by:
1. Adding it to the build
2. Adapting it a bit so rounding errors really don't trigger (as the
original commit claimed they shouldn't).
3. Re-renaming it because this was actually about 3d gradients
The actual gradient line is covered by blocks, so there are no
artifacts. But if a renderer screws this up, the blue/red will seep
through these blocks.
This test tests multiple things:
1. That huge contents are properly clipped by repeat nodes, even if the
repeat happens in the visible part
2. That repeating only horizontally or only vertically is done quickly
via offscreens when lots of repeating is done
Test that if the child is a texture that extends the child bounds, that
extension does not get repeated when rendering.
This can easily happen when the child is not drawn as an offscreen, but
instead the texture cache is consulted and no check for matching size is
done.
Instead of using "-3d" to exclude Cairo rendering, use "-no$renderer" to
allow excluding any renderer.
And because we use contains() for the check, we can exclude multiple
renderers by naming the test sth like "test-nogl-nocairo.node"
This is the result of experimenting with corner cases when blurring.
The result is a test that tests when the child of a blur node is
clipped out but the blurred child is not, the blurred parts are still
visible.
This immediately broke the cairo renderer, so the fix is included.
These are 2x2 combinations that:
1. Use a texture child node vs a color child node
This should force an offscreen vs straight up use a texture.
2. Switch opacity and color-matrix
Either put the color matrix into the opacity node or put the opacity
into the color matrix.
This is worth testing because renderers often combine opacity into the
color matrix to avoid offscreens.
And they do that because applications often create faded out symbolic
images, which end up as a combination of these nodes.
Add a wayland_gl setup that explicitly uses desktop GL, and rename
wayland_gles to wayland_gles2 (since that is what it does).
In ci, make the fedora-x86_64 runner run tests with wayland_gl
and wayland_gles2, and make the fedora-release runner run test
with wayland and x11.
These tests come in two variants.
The first takes .node and .offload file, parses the node file,
and compares the resulting subsurface attachments to expected results.
The second variant takes two .node/.offload file pairs and a .diff
file, parses the node files, compares the resulting subsurface
attachments, and then diffs the nodes, comparing the resulting
area to the region in the .diff file.
Check that the right filter is chosen and that that filter is
implemented correctly.
The test is disabled for Cairo because Cairo (or rather Pixman)
doesn't follow the filtering specifications for GL/Vulkan and in
particular the nearest filter picks a different pixel.
When shadows were offset - in particular when offset so the original
source was out of bounds of the result - the drawing code would create a
pattern for it that didn't include enough of it to compose a shadow.
Fix that by not creating those patterns anymore, but instead drawing the
source (potentially multiple times) at the required offsets.
While that does more drawing, it simplifies the shadow node draw code,
and that's the primary goal of the Cairo rendering.
Test included.
The code now follows gsk_rounded_rect_shrink() and with it the behavior
of the Cairo renderer and Webkit.
The old code did what the GL renderer and Cairo do, but I consider that
wrong.
I did not test Chrome.
Test attached
Cairo and the GL renderer have a different idea of how to handle
transitioning of colors outside the defined range.
Consider these stops:
black 50%, white 50%
What color is at 0%?
Cairo would transition between the last and first stop, ie it'd do a
white-to-black transition and end up at rgb(0.5,0.5,0.5) at 0%.
GL would behave as it would for non-repeating gradients and use black
for the range [0%..50%] and white for [50%..100%].
The web would rescale the range so the first stop would be at 0% and
the last stop would be at 100%, so this gradient would be illegal.
Considering that it's possible for code to transition between the
different behaviors by adding explicit stops at 0%/100%, I could choose
any method.
So I chose the simplest one, which is what the GL renderer does and
which treats repeating and non-repeating gradients the same.
Tests attached.
This tests the merging of nested color matrix nodes feature of
GtkSnapshot, which was broken before commit 082fdfdb24.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
This takes a render node tree and "replays" it by using the GtkSnapshot
machinery. We don't necesserily expect to get back an exactly equal
render node tree back, since GtkSnapshot applies various small
optimizations where possible, but the original and the replayed nodes
should render to identical textures.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Inverted alpha masks have an effect on the source, even if the mask
doesn't cover the source at all - or worse, is completely clipped out.
The GL renderer handles this fine, but Cairo and Vulkan had
optimizations that got this wrong.
In particular, fix the combination of luminance and alpha. We want to do
mask = luminance * alpha
and for inverted
mask = (1.0 - luminance) * alpha
so add a test that makes sure we do that and then fix the code and
existing tests to conform to it.
