Some GL functions can be called using different names depending on the
GL version and available extensions (ARB, EXT). The dispatch table
abstracts these differences and provides a uniform API for dealing with
these functions.
Holding the mutex over glyph lookup not only prevents multi-threaded
races between insertion and deletion that spell disaster for memory
integrity, but also implies that the glyph cache is frozen.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gcc complains that:
cairo-path-fixed.c:400: warning: inlining failed in call to
'_cairo_path_fixed_drop_line_to': call is unlikely and code size
would grow
The recent (and not-so-recent) changes in gradient code changed the
results of some tests involving gradients.
radial-gradient-* tests are marked XFAIL for pdf because poppler is
not sampling the color function with a sufficient frequency, but they
look correct in Adobe Reader.
If all the stops of the gradient have the same offset and the
pattern's extend mode is EXTEND_PAD, then we cannot use the stops'
domain as the interpolation parameter range because this would produce
a gradient with the same start and end objects. Such ranges tickle
bad behaviour in rasterisers.
We replace the color function with an appropriate step function
defined on [0 1].
Fixes radial-gradient-one-stop for pdf and ps3.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
To draw repeated gradients in ps, which only supports none and pad
extended gradients, we need an appropriate reparametrization of the
gradients that will cover the whole clip region without needing
repeats.
This commit adds support for the drawing of reflect/repeat-extended
radial gradients through native ps patterns, using pad-extension and
no fallbacks.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
To draw repeated gradients in pdf, which only supports none and pad
extended gradients, we need an appropriate reparametrization of the
gradients that will cover the whole clip region without needing
repeats.
This commit adds support for the drawing of reflect/repeat-extended
radial gradients through native pdf patterns using pad-extension and
no fallbacks.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=28870
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
Share code between linear and radial gradients, using
_cairo_gradient_pattern_box_to_parameter() instead of open coding the
parameter range computation.
As a side effect this fixes parameter range computation for radial
gradients, because the previous code assumed that the focal point was
inside the circles.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
This will be a common function used by the quartz, ps, and pdf
backends when rewriting EXTEND_REFLECT/REPEAT gradients in terms
of EXTEND_PAD gradients.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
This patch adds support for analysing the transparency of a
radial gradient within some area of interest. Before the code
would ignore the extents for radial gradients. Linear gradients
now use _cairo_linear_pattern_box_to_parameter() allowing us
to remove the superfluous _extents_to_linear_parameter().
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
This makes it possible to compute the interpolation range needed to
correctly draw a gradient so that it covers an area of interest.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
_cairo_pattern_is_opaque() returns false for none-extended linear
gradients and for radial gradients, but fallback is only needed if
they have non-opaque stops.
This can be tested using _cairo_pattern_alpha_range(), which only
analyses the part of the pattern which is drawn.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
Both the ps and pdf backends are open coding analyses of the
range of pattern alphas. This patch factors out a new function
_cairo_pattern_alpha_range() to do that for them.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
Use the tests for degeneracy and new radial gradient definition
when computing pattern extents. Degenerate gradients are optimised
away by cairo-gstate into solid or clear patterns, and
the radial gradients semantics have changed to match PDF semantics.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
Change the signature of type-specific functions to make them only
accept the correct pattern type instead of the abstract cairo_pattern_t.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
_cairo_polygon_limit() had to be called immediately after
_cairo_polygon_init() (or never at all).
Merging the two calls is a simple way to enforce this rule.
Using _cairo_path_fixed_interpret_flat() greatly simplifies the path
to polygon conversion (because it already converts curve_to's to
line_to's).
This commit also removes the optimization which merges two consecutive
lines if they have the same slope, because it's unlikely (since it
should already happen during path construction), it doesn't provide
better performance (at least not measurable with the currently
available cairo-traces) and bloats the code.
Path are always interpreted in forward direction, so the ability of
interpreting in the opposite direction (which is very unlikely to be
useful at all) can be removed.
All other pdf drawing functions have been updated to use
cairo_composite_rectangles_t to compute the extents affected by the
operation in 3a5d71c431, but fill_stroke
was not changed.
This removes the last usage of the old _cairo_surface_*_extents()
functions.
The handling of angles above 2pi in cairo_arc is not very solid and is
basically untested.
This test should ensure that changes in the behavior will be noticed
by the testsuite.
To limit the amount of memory used for arcs describing a circle
wrapped multiple times we ignore the circles after the 65536th (but
preserve the same start and end angle mod 2pi).
Adding/subtracting 2 * M_PI to a huge floating point number doesn't
change it (because of rounding) and for smaller numbers it still
requires a lot of cycles before the angle is in the desired range.
The same computation can be performed using fmod, which should provide
more accurate results and only requires O(1) time.
In https://bugs.launchpad.net/ubuntu/+source/libcairo/+bug/680628 a
65K PDF printed to PDF using poppler-cairo turns into an 8MB PDF. The
original PDF contains a very large number of stencil mask images (an
A1 image used as a mask for the current color). The PDF surface was
not optimized for this particular case. It was drawing a solid color
in a group and then using an smask with the image in another group.
Fix this by checking for source = solid and mask = A1 image and
emitting a stencil mask image.
Go through each Charstring looking for the local and global
subroutines called. To avoid modifying the Charstrings [1], the unused
subroutines are reduced to a single byte return op [2] leaving the
remaining subroutines in their original array index position.
Results of testing with some CFF fonts with a 26 glyph [a-z] subset:
Font Subset size: Before After
-------------------------------------------------------
LinBiolinum_Re-0.6.4.otf 48,423 8,295
LinBiolinum_It-0.5.1.otf 88,942 11,501
LinBiolinum_Sl-0.4.9.otf 89,231 11,505
LinLibertine_Re-4.7.5.otf 51,125 8,654
LinLibetine_It-4.2.6.otf 59,333 9,632
Inconsolata.otf 13,826 8,407
[1] Further reductions could be obtained by stripping out unused
subroutines and renumbering the remaining subroutines but is more
complicated due to the encoding used for subroutine numbers that is
both variable length and a function of the size of the subroutine
array.
[2] Poppler and Fontforge do not seem to like zero length unused
subroutines.
An A1 image with full alpha should be opaque black, not opaque white.
Use specialized solid black image instead of the generic constructor
for an A8 image with full alpha (it is likely to be cached).
The input of _fill_unaligned_boxes is (supposed to be) composed only
of disjoint rectangles, that can safely be passed to the rectilinear
span converter, but this function artificially introduces intersecting
rectangles when drawing non-aligned boxes.
Using non-intersecting rectangles is easy and makes the code correct.
Fixes rectilinear-grid.
Reviewed-by: Uli Schlachter <psychon@znc.in>
The rectilinear scan converter assumes disjoint rects as input, but
cairo-image passes intersecting rectangles to it.
This test shows that image and any backends passing through it for the
rasterization (fallbacks, vector backends whose renderer is
cairo-based) fail in compute the corners of intersecting rectangles
correctly.
The recording surface source image painted onto fallback images always
had the resolution 72ppi instead of the fallback resolution of the
target surface. Fix this by passing adding a new
acquire_source_image_transformed backend function for the recording
surface to use and passing the target device transform through to the
recording surface when the image is acquired.
Based on Carl Worth's experimental acquired_source_image_transformed
branch.
https://bugs.freedesktop.org/show_bug.cgi?id=24692
