This tests the fixes in aa82190da659b5 and dcaa2c4ccb182c74cb40.
The test uses a custom font named 'text-mixed-color' which contains
six glyphs that are just boxes. Glyphs 1, 2, 3 are just plain glyphs,
and glyphs 4, 5, 6 are color glyphs in red, green and blue.
The glyphs are mapped to the characters A, B, C, D, E, F.
The test is currently disabled for cairo, since it has some issues
with transformed color glyphs.
The commit adds a custom fontconfig configuration in
testsuite/gsk/fonts/fonts.conf and sets the FONTCONFIG_FILE
environment variable for the gsk compare tests to point at it.
To use a custom font in tests, just drop it into the
testsuite/gsk/fonts/ directory.
The font configuration includes the system configuration,
so existing tests should not be affected.
Fill a rectangle with fractional coordinates << 1.0 but scale it up so
that it ends up being nice integers.
Makes sure that nobody does any bad rounding here.
The Vulkan renderer can just be public API, because it doesn't expose
any Vulkan-specific APIs.
And it can just exist when compiled without Vulkan, because it can fail
to realize.
Also move get rid of the gsk/vulkan/gskvulkanrenderer.h header. It was
experimental and isn't necessary now that the renderer is included via
gsk.h.
Add a testsuite called gsk-compare-vulkan to run
the gsk renderer tests with the Vulkan renderer and
gsk-compare-ngl to run them with the NGL renderer.
To run the tests locally, you can do:
meson test -C_build --suite gsk-compare-vulkan
gdk_texture_save_to_png_bytes() cannot fail, so ensure that it doesn't.
Testsuite has been updated to check for this case.
Note that we do not load the PNG file that we generate here.
Loading is a lot more scary than saving after all.
If people want to load oversized PNG files, they should use a real PNG
loader.
If there are more than 7 color stops, we can split the gradient into
multiple gradients with color stops like so:
0, 1, 2, 3, 4, 5, transparent
transparent, 6, 7, 8, 9, 10, transparent
...
transparent, n-2, n-1, n
and use the new BLEND_ADD to draw them on top of each other.
Adapt the testcae that tests this to use colors that work with the fancy
algorithm we use now, so that BLEND_ADD and transitions to transparent
do not cause issues.
We want to introduce a new one next.
Technically, this breaks API, because gsk_vulkan_renderer_new() is going
away, but practically, we're gonna bring it back once we introduce that
renderer in a few commits.
The test ensures that offscreens render to the same pixel grid as the
actual image, and they are not offset by fractions of a pixel.
The Cairo renderer fails here because Cairo's clipping code rounds pixel
values wrong.
Testcase included
The code was writing invalid memory, so this might not have always
crashed, but I did my best to write the test so it causes a SEGV.
Also included is a fix for the testsuite where the expected result was
wrong.
The replayed node/images weren't saved.
I wanted to check that an optimization is done when replaying a test,
but without a saved node file, I couldn't.
It is not material to this test, and it causes some hard to
understand problem with fontconfigs use of mmap, leading to
a sporadic segfaults in pangos fontconfig thread.
This test fails on my system currently, since rawhide libpng appears
to have changed the encoding of pngs so that the texture nodes no
longer match the reference. This will be a problem as long as our
ci systems have an older libpng, so disable this test for now.
These 2 rectangles used to intersect fine:
0 0 50 50 / 50 0
0 0 50 50 / 0 50
But the computed result was:
0 0 50 50 / 50
which is not a valid rectangle, because the corners overlap.
Make sure such rectangles return NOT_REPRESENTABLE.
The above rectangle has been added to the testsuite.
There are some tests that generate large images.
However, if we mask that image, we might have to generate offscreens
both for the source and for the mask.
And if we do that, it can take a long time. And especially on CI with
software rendering, that can quickly become noticable and result in
timeouts.
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.
When we test repeat nodes, make sure we round the size of the original
node up to an integer.
The reference image for the node is a rounded up, so when we generate a
new reference image we cannot deal with anything else.
Fixes huge-width test with --repeat.
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.
When passing a directory via G_TEST_SRCDIR, still pay attention
to --verbose, and print out each file thats tests. This lets us
quickly pin down which test fails.
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.
We did have 4 ordering variations of ARGB straight,
but only 3 premultiplied. Add the missing one.
Update all the places where we switch over memory formats.
We always have a display - the default display - so there's no need to
accept NULL.
Plus, we need a display when building the texture, so accepthing NULL
wouldn't even make sense.
Includes update to defaultvalue test.
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.
These are the dmabuf formats that we can import
into a GL context as an EGLImage, and successfully
download.
We skip the GdkDisplay:dmabuf-formats property
in the default value tests, since the nominal
default value is NULL, but the actual value is
constructed on demand.
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.
Make circle contours use 'foreach coordinates' for
its points. This works here, but not for general
conics. As with the other custom contours, avoid
emitting collapsed conics.
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.
Add a contour that optimizes some things for
rectangles. Also add rectangle detection to the
path parser, and add tests similar to what we
have for the other special contours.
Check that the start- and endpoint work
as expected and verify that their winding
numbers match the ones of the standard contour,
and are negated when the contour is reversed.
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>
We don't need to have the derivative as a curve,
it is enough for us to compute values of the
derivative at a given t, which we can also do
for conics.
Arcs were appealing, but they have a fatal flaw: we can't
split our arcs without changing the ellipse they trace.
That could be fixed by adding an extra parameter, but then
it is no longer any better than conics.
So switch back to conics, which have the advantage that they
are used elsewhere.
Add a new curve type for elliptical arcs
and use it for rounded rectangles and circles.
We use the 'E' command to represent elliptical
arcs in serialized paths.
FLT_EPSILON is the distance between 1.0 and the next distinct floating
point number, and doesn't necessarily have anything to do with the
precision we can expect from a series of floating-point calculations.
Experimentally, 1e-6 is achievable, even on platforms with unusual
floating point implementations like i387.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6051
Bug-Debian: https://bugs.debian.org/1050076
Signed-off-by: Simon McVittie <smcv@debian.org>
When redoing a history entry, its `is_modified` flag is not
reflected to the history state tracker. So GtkTextBuffers may
expose a modified=FALSE status, despite a change was actually
applied to the buffer.
For the undo case, an `is_modified_set` flag was set on the last
entry of the undo queue when a change of the modified state of
the history is requested. This commit does the same on the first
entry of the redo queue.
Closes#5777
The builder test was relying on default visiblity
for non-static functions. Make it explicit that we
want to export these functions, so the test keeps
working when we change the default visibility.
The relevant question here is about details, because we have to choose
if we declare alpha-only formats as having their (nonexistant) color
channels premultiplied or not, so that the code paths using them can do
the right thing.
Because we are premultiplied by default, it makes sense to treat alpha
like that, because then the alpha-only code doesn't need to do
workarounds for straight alpha.
Where this is relevant of course is when expanding the alpha channel
into color channels, where we want to end up with white.
So make sure we do color = alpha there instead of color = 1 like we did
before.
We need them for mask-only textures.
For tiffs, we convert the formats to RGBA (the idea that tiff can save
everything needs to be buried I guess) as tiffs can't do alpha-only.
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.
