The idea is being able to generate shaders from the given input
on-demand. This allows creating more advanced shaders, such as those
that include the destination (for self-painting and
unsupported-by-blending operator) or painting images in weird formats
(extra translation step in shader, think YUV).
Previously the glyph advance in font units was used for the widths in
the PDF font dictionary. This only works for cff fonts that use a
[0.001 0 0 0.001 0 0] font matrix.
Previously the glyph advance in font units was used for the widths in
the PDF font dictionary. This only works for Type 1 fonts that use a
[0.001 0 0 0.001 0 0] font matrix.
https://bugs.freedesktop.org/show_bug.cgi?id=28061
Required for successful linking of our programs. I am not sure what the
impact this has upon other users of Cairo yet, I think we need to export
the PTHREAD_CFLAGS via cairo.pc as well.
Those paths were broken, as they didn't properly translate the polygon
to the destination size. And rather than adding lots of code that allows
translation, it's easier to just delete this code.
Note that the only user of the code was the GL backend anyway.
We get circular references that way.
If it turns out later such a cache is critical, we'll need to invent a
way to avoid circling references. For now, just pretend it's not
important.
Clarify that cairo_pattern_create_rgb() and cairo_pattern_create_rgba()
should be be overloaded as a single constructor for SolidPattern, but
instead should be static methods.
Hopefully reduce the occurrence of the confusion between the
premultiplied shorts in cairo_color_t and the non-premultiplied shorts
in cairo_color_stop_t.
The existence of the two separate types is debatable and open for
review.
color stops are not premultiplied so we need to handle them carefully
when comparing. The next step will be to make cairo_color_stop_t a
unique type to prevent this mistake again.
on src/cairo-composite-rectangles.c
The extent of the operation can be larger than the source if
the operator is not bounded by the source.
Fixes clip-unbounded, operator-source, surface-pattern-operator
Only during infrequent eviction do we require absolute knowledge of
which graph of nodes are in use and thus pinned. So during the common
use of querying the glyph cache, we just mark the leaf as used. Then we
need to make space for a new glyph, we move the parents of the left
nodes from the evictable list to the pinned list.
The reuse hit rate is very small, and most images are quickly
distinguished in the first few bytes... Though perhaps not for video as
in the swfdec-youtube case...
I accidentally pushed this debugging left-over from when I was tracking
down a race in memfault. Remove it so that the test suite compiles on
more minimal pthread setups.
I discovered a small bug in cairo-quartz gradients. If you have multiple stops
at position 0, then cairo-quartz pads with the *last* stop at position 0,
instead of the first stop at position 0. This patch fixes that.
From https://bugzilla.mozilla.org/show_bug.cgi?id=513395
-- Add a parameter to _cairo_quartz_setup_source so we can pass down the
extents of the object we're drawing
-- Compute fill/stroke/glyph extents and pass them down in the cases we need to
(repeating/reflecting gradients)
-- Pass those extents on down to where we set up the gradients
-- Make _cairo_quartz_setup_linear_source fall back to pixman for the
degenerate case where the linear gradient vector has no length
-- In CreateRepeatingRadialGradientFunction and
CreateRepeatingLinearGradientFunction, use the object extents (or surface
extents, for the paint() case) instead of the clip box to calculate the
parameters for the gradient
-- I've changed the way CreateRepeatingLinearGradientFunction calculates the
repetition count. The new approach gives much more precise bounds on the number
of repetitions needed (and is very similar to what we do for radial gradients).
This is important because if we specify a much larger input range than we
really need for our gradient color function, Quartz samples it too coarsely
over the range we actually care about, and the gradients look bad.
For example, suppose start = (5,0), end = (6,10), the CTM is identity and the
bounds we want to cover is (0,0)-(10,10). I think the current approach sets up
the gradient to be repeated 10 times. In fact only 3 repetitions are needed.
Also, using 'width' here didn't look right:
- y_rep_end = (int) ceil((surface->extents.width - MAX(mstart.y, mend.y))
/ dy
From https://bugzilla.mozilla.org/show_bug.cgi?id=508730
