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.
Mask nodes are transparent outside of the intersection of source and
mask, unless the mask ode is inverted alpha.
Set the bounds accordingly.
Tests have been updated accordingly.
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.
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.
We need to provide color stops to avoid rounding errors with different
shaders.
That makes the empty linear gradient somewhat less empty, but I think
it's the emptiest we can make it.
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.
Without an explicit width, height, and viewBox, there is no single
correct way to render an SVG. In the absense of said information,
librsvg is capable of making a guess by rendering the SVG to a Cairo
surface and then analyzing that surface; however, this process is
merely heuristic.
There are three GTK tests for SVG images that are missing dimensions.
While this is not a violation of the SVG specification, it does
implicitly couple the test to the librsvg rendering heuristic. In this
commit we add that dimension information so that the expected result
is unambiguous.
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>
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.
Make it use an alpha value that is well defined, ie 0.4 instead of 0.5.
0.4 * 255 = 102
0.5 * 255 = 127.5
This avoids rounding issues where some math may cause the resulting
alpha value to be 127, and some other math ends up with 128.
This one tests a crossfade between two non-overlapping nodes with a clip
region that covers neither of the two nodes.
This tests that renderers can deal with clip regions that doesn't
overlap nodes in a situation where they will most likely want to create
an offscreen.
As offscreens are typically clipped to the clip region, this would cause
an empty offscreen and that can cause failures.
This was an experiment where an offscreen was translated inside an
existing clip.
Because renderers try to limit offscreens to the clip rect, this is
interesting, because they might get the translation wrong.
