Add a way to find the intersections of two curves.
We can handle some curve-line intersections directly,
the general case is handled via bisecting.
This will be used in stroking and path ops.
Take a rendernode as source and a GskPath and GskStroke,
and fill the area that is covered when stroking the path
with the given stroke parameters, like cairo_stroke() would.
This commit adds GskPath, GskPathPoint and GskPathBuilder.
GskPath is a data structure for paths that consists
of contours, which in turn might contain Bézier curves.
The data structure is inspired by Skia, with separate
arrays for points and operations. One advantage of this
arrangement is that start and end points are shared
between adjacent curves.
In addition to the usual contours comprised of Bézier
segments, GskPath supports certain special contours
directly, such as rectangles, rounded rectangles and
circles.
The GtkFileDialog code was asserting that
we get exactly one file back. But the function
is nullable anyway, so lets just return NULL
if we don't have a file.
Fixes: #5975
Instead of scale and whatnot, pass:
1. The image size
2. The viewport to map to that image size
and compute everything else from there.
In particular, we set the Vulkan viewport to the image dimensions
instead of the viewport size.
All of this makes things a lot simpler while keeping the required
functionality.
If people specify the filename, they should know what they're doing.
If they don't, abort if the guessed filename already exists and insist
on the user explicitly giving it.
As pointed out in #3417, there is a long-standing
difference in how GtkEntry and GtkTextView treat
Ctrl-Shift-Backspace (and other variations): GtkEntry
always operates on the selection first, if it exists.
GtkTextView only handled plain Backspace that way, and
ignores the selection for other variations.
There is no good reason for this difference, so just
remove it and make GtkTextView behave the same as
GtkEntry.
Fixes: #3417
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.
Add a bunch of inline functions for graphene_rectangle_t.
We use those quite extensively in tight loops so making them as fast as
possible via inlining has massive benefits.
The current render-heavy benchmark I am playing (th paris-30k in node-editor)
went from 49fps to 85fps on my AMD.
