Commit f5159e1ecb introduced more flexible ways of specifying
glyph strings in node files, but it used ink rect width instead
of the more appropriate advance width when reconstrucing the
glyph string.
Fix expected output of one test to match.
3 things you need to know about this change:
1. We use diff(1) in various tests to check generated text against
reference output
2. Windows locates executables not just in $PATH, it also looks in
$cwd and the directory of the current process' binary
3. Multiple tests live together in the same directory
Windows is fun.
use the modern version using GSubprocess that already exists in
node-parser.
Also change from one function to two - so tests can diff GBytes and
strings, depending on which they prefer.
On Windows, git defaults to maintaining line endings, which means it
changed \n to \r\n on all files it identifies as text. And that includes
our test output.
Luckily diff(1) has an option to undo that. And since we do not care
about line endings in those tests, we can just use it.
When GL or Vulkan is not supported, the test should not fail.
It would be nicer if we could detect GL/Vulkan not being available
otherwise, but I'm not aware of a better solution, in particular because
rendeers might have stricter requirements than GTK itself.
So this is the next best fix.
On top of that we defined a preprocessor constant to 2 different
values, but instead of checking the value, we only checked if
it was defined. Now we only define it in one place.
No.
This fix is not that much better, but I'm too tired to fix stuff
like this properly.
And the Cairo renderer did at least work everywhere during 4.x
Somebody came up with the great idea of content types, which
are just like mime types, only that they aren't on Windows.
So if we want a working testsuite that actually works on Windows,
we cannot mix them up.
If that flag is set, we keep the bounds of the original node when
rendering the modified node.
Gets around the replay test having to draw a transparent color node to
ensure the same bounds.
Compositors don't guarantee that there's any physical devices
around to correspond to the input capabilities.
This was found running the tests against mutter headless.
The clip might be different from the scissor due to incompatible
intersections.
But the resulting intersection might be fully clipped, so we should
consider it.
Testsuite with longer explanation attached.
Fixes#7044
Due to a Mesa bug, RGBA16 images aren't properly handled sometimes and
can cause random failures.
In this case, generating the modified reference images for the tests
fails.
Fixes CI breakage.
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11750
