Add a --colorflip option to the compare-render test. This applies
a color matrix to the node, which has the intended side-effect of
convincing the Vulkan renderer to use its uber shader, so we get
test results comparing the uber output to its non-uber siblings.
Test included.
The test is disabled for Cairo because the Cairo blurring code can't
deal with scaling, which makes things come out wrong for the test that
checks that we do the right thing with the blur radius when scaling.
Related: !6977
These tests check that we round glyph positions to integral device
pixel coordinates when hinting is enabled, and to device subpixel
positions if it isn't.
We want to test subpixel positioning, so turn off hinting, since
hinting and subpixel positioning are opposing forces.
This does not currently change test outcomes, but it will prevent
the tests from breaking in the future when we make changes to
improve hinting.
The glyph in this test has extents that will be made smaller
by hinting, which poses some challenge for our renderers.
The scaled glyph rendering is too big for the 'small texture'
text setup, so we allow the test to fail there.
The goal is to fix all the context that influences the rendering
of text nodes in the node file. This will help with better font
testing.
The newly accepted properties are
hint-style: none/slight/full
antialias: none/gray
We are omitting font options and values that aren't supported
in GSK or have no influence on the rendering.
Note that these settings will get incorporated in the PangoFont
that gets set on the resulting text node.
Parser tests included.
The pango code that is drawing hex boxes, invisible glyphs, etc,
is depending on the width being set in the PangoGlyphInfo. Once
we set that, everything falls into place.
Testcase included.
It is a bit annoying that one has to specify the glyph width
when specifying glyphs numerically for a text node, since this
information really is part of the font.
Make the parser more flexible, and allow to specify just the glyph
ids, without an explicit width. In this case, the width will be
determined from the font.
With this, glyphs can now be specified in any of the follwing
ways:
glyphs: "ABC"; (ASCII)
glyphs: 23, 45, 1001; (Glyph IDs)
glyphs: 23 10, 100 11.1; (Glyph IDs and advance widths)
glyphs: 23 10 1 2 color; (with offsets and flags)
Tests have been updated to cover these variants.
In an autobuilder environment, there will typically be no hardware GPU
available, so Mesa will fall back from hardware to Zink to software
rendering. Unfortunately, Zink logs to stderr during loading if no
hardware GPUs are available. This particular test asserts that stderr
has desired contents, which means Zink's extra output causes the test
to fail. We can bypass this by disabling use of Zink.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6478
Signed-off-by: Simon McVittie <smcv@debian.org>
The text-mixed-color-nocairo test was using a 20pt font, which
results in 16.6 pixels, which is prone to triggering rounding
errors and problems with fractional node bounds. Make it use
20px instead.
Previously the code for calculating the cursor and anchor for the
flipped case was mixed up with the logic for the non-flipped case.
Additionally make the code more readable by making the anchor/selection
bound the start and the cursor/insert the end of a selection. Thus a
selection made from left to right goes from start to end. Selections
from right to left, i.e. end to start are considered flipped.
Also update the test to use the correct cursor/anchor and change some
variable names to make it more readable.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/6460
To make it work on macOS, do not add typelibdir to GI_TYPELIB_PATH.
While this change affects all the other jobs as well, it appears to
be of no consequence.
Avoids getting the scale wrong when due to a rounding error our
pixel-aligned rectangle is 5.000000003px big and we ceil() to 6px
and produce blurry output.
Fixes#6439
This tests that the result is suitably clipped for doing linear
blending - the rightmost green pixel that is technically offscreen
is blending into the red pixel and turning the test yellow.
Cairo gets this wrong for some reason I didn't investigate.
Add rounded rect intersection tests with difficult rounded rects
where the corners are not disjoint (the 'evil eye').
The first half of these tests were provided by Benjamin Otte
in #6440, the other half was added by me to cover the flipped
version of the evil eye.
g_test_init has the ugly habit of aborting if G_DISABLE_ASSERT
is defined, and we want to run our tests in a release build too.
Use gtk_test_init instead, which works around this issue.
It includes a fallback list of fourccs. Otherwise we might miss some
DRM_FORMAT definition.
This happens in SLES12:
```
../testsuite/gdk/dmabufformats.c: In function ‘test_dmabuf_formats_basic’:
../testsuite/gdk/dmabufformats.c:29:56: error: ‘DRM_FORMAT_ABGR16161616F’ undeclared (first use in this function); did you mean ‘DRM_FORMAT_ABGR2101010’?
29 | g_assert_true (gdk_dmabuf_formats_contains (formats, DRM_FORMAT_ABGR16161616F, DRM_FORMAT_MOD_LINEAR));
```
Look for nodes like subsurface { clip { texture {} } }, and use
the clip to provide a source rectangle for subsetting the texture.
Update affected tests, and add a new one.
This will let us use a subset of the full texture, which can
be necessary in the case that converters put padding around
content in dmabufs. The naming follows the Wayland viewporter
spec.
For now, make all callers pass the full texture rect.
We are going to introduce another rect, so better to be clear in
naming. We are following the naming of the Wayland viewporter spec
and call the rectangle that we drawing into the dest(ination).
We can just check if the subsurfaces contain content - and if they do,
they will be offloading and we can ignore the diff.
This essentially reverts 48740de71a
Instead of relying on diffing subsurface nodes, we track damage
generated by offloaded contents inside GskOffload.
There are 3 stages a subsurface node can be in:
1. not offloaded
Drawing is done by the renderer
2. offloaded above
The renderer draws nothing
3. offloaded below
The renderer needs to punch a hole.
Whenever the stage changes, we need to repaint.
And that can happen without the subsurface's contents changing, like
when a widget is put above the subsurface and it needs to to go from
offloaded above to below.
So we now recruit GskOffload for tracking these changes, instead of
relying on the subsurface diffing.
But we still need the subsurface diffing code to work for the
non-offloaded case, because then the offloading code is not used.
So we keep using it whenever that happens.
Not that when a subsurface transitions between being offloaded and not
being offloaded, we may diff it twice - once in the offload code and
once in the node diffing - but that shouldn't matter.
The dmabuf texture tests are failing, so we don't run them in
ci, but the format tests are perfectly fine, so split them off.
Add some tests for GdkDmabufFormatsBuilder and for the new
gdk_dmabuf_formats_equal(), too.
The node processing wasn't skipping 0-size nodes when using the
uber shader, leading to assertions down the road. Since the ngl
renderer doesn't use uber shaders, this only affects vulkan.
Test included.
Fixes: #6370
When we don't have an embedded font file via a url, then we want
to parse fonts "as normal", i.e. allow fallback for aliases like
"Monospace 10". This was broken when the url support was added.
Make it work again.
Update affected tests. In particular, the output of the text-fail
test goes back to be the same it was before the url changes.
See previous commit for an explanation of the problem.
This test actually draws a rounded border, but the rounding is clipped
away. What is remaining is the 4 corners of the border, where the
top/bottom color is red and the left/right color is green. But because
the bottom/right side has a width of zero, the result should be all red.
We are not catching bugs when inserting if we're right at a boundary.
This because we never add or remove items from a section. We only ever
add or remove whole sections.
Introduce a test which inserts items at a random position inside of a
section.
With the --repeat version of this test, Cairo needs to draw partially
clipped glyphs. However, there's a bug in Cairo where it doesn't account
for the subpixel positioning when clipping, so the glyphs get cut off at
the edge.
This is filed as https://gitlab.freedesktop.org/cairo/cairo/-/issues/821
Draw a grid of 21x21 box glyphs.
Each glyph is offset by n/20 pixels in the x and y direction.
The background color is carefully selected to be divisible by 16, so
that when the box glyph is subpixel positioned by 1/4th of a pixel
offset from the pixel grid in either direction, the result will be an
edge pixel whose color value can be computed exactly.
Cairo still rounds this wrong for color values >= 128 which is why we
use a dark gray that guarantees the resulting color values are all <128.
Clip from 1025px (which is what this test is about) to 1024px because the
GLES2 renderer in CI otherwise scales its repeat node offscreen for the
--repeat version of this test and that conveniently produces off-by-one
misrenderings everywhere.
However, we need to keep the image large enough so that all the glyphs
are actually rendered and not skipped which would not overflow the
cache.
This test is specifically engineered to trigger an overflow in the glyph
renderer that was theorized on IRC with an earlier patchset.
If only one slice was available, and that slice was not high enough to
hold the glyph we were trying to put in there, it would allocate a slice
that was too small. The check for the size was missing.
So now add a test that fills up all the slices in the glyph cache apart
from one and than tries to add one final glyph that is too large for the
last slice.
After the node-editor crashed on me once too often, I decided to take a
good hard look at the parsing code and add a bunch of weird corner
cases into the testsuite.
That meant redoing the parser so that the error paths cause neither
crashes nor duplicated or wrong error messages.
The gl renderer has an optimization where it uses the glyph atlas
to render color nodes that show up in the middle of text (e.g. for
underlines and carets). This adds a simple test for that scenario,
which hits this codepath.
