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.
After discussion on IRC about debug messages:
- FALLBACK is meant to be used for printing stuff about fallbacks
(Cairo, offscreens, conversion when uploading, etc)
- CAIRO is for overdrawing everything drawn with Cairo
When hilighting Cairo nodes, use a different hilight color than when
hilighting other nodes.
This allows differentiating application use of Cairo (via nodes) from
renderer use of Cairo (via fallback).
Use it to overlay an error pattern over all Cairo drawing done by
renderers.
This has 2 purposes:
1. It allows detecting fallbacks in GPU renderers.
2. Application code can use it to detect where it is using Cairo
drawing.
As such, it is meant to trigger both with cairo nodes as well as when
renderers fallback for regular nodes.
The old use of the debug flag - which were 2 not very useful print
statements - was removed.
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.
When different scale factors are used to transform a diagonal
linear gradient, the angle between the gradient line and its
perpendicular is no longer a right angle, which makes the
gradient come out different.
So it is necessary to use transform nodes in that case so that the
correct gradient gets rendered.
Technically, the code could check if the scales are equal or the
gradient line is horizontal/vertical, but I don't think that's worth it.
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"
Sync the code in gtkwindow.c that generates focus change events
with the similar code in gtkmain.c that generates crossing events.
This fixes assertion failures that would trigger in nautilus when
opening a folder.
We don't want to set a misleading descendent in the case that
we don't have a shared ancestor at all (because the old and the
new targets are on different toplevels).
Doing this in a way that is picked up by gobject-introspection
requires splitting off new enum members into separate doc
comments, which is a bit unfortunate.
