Based on feedback from Jeff Muizelaar, there is a case for a very quick
and dirty extents approximation based solely on the curve control points
(for example when computing the clip intersect rectangle of a path) and
by moving the stroke extension into a core function we can clean up the
interface for all users, and centralise the logic of approximating the
stroke extents.
When analysing the stroke extents, we need the original fixed-point
extents so that we do not incur an OBO when we round-to-integer a second
time. We also need a more accurate estimate than simply using the control
points of the curve, so pass in tolerance and decompose until someone
discovers a cheaper algorithm to determine the precise aligned bounding
box of a bezier curve.
If we are dithering on the Xlib backend we can not simply repaint the
surface used for a solid pattern and must recreate it from scratch.
However, for ordinary XRender usage we do not want to have to pay that
price - so query the backend to see if we can reuse the surface.
When coercing from one image format to another we performed a paint
operation using a temporary context - this is overkill as we can just call
_cairo_surface_paint() directly.
This commit moves the toy-to-real mapping from the scaled font creation
time to font face creation. A toy font face will keep an internal ref
to an implementation face. Then cairo_scaled_font_create() will simply
substitute the implementation face before creating anything.
This also modifies the cairo-ft toy creation in that we now create a
non-resolved pattern and store it in a cairo-ft font-face. We then
do the resolving and unscaled font creation at scaled-font creation
time. This also means that cairo_ft_font_face_create_for_pattern()
now accepts non-resolved patterns too, and does the right thing about
them. As much as that can be called right.
Some testing of toy font creation performance is in order, as is testing
win32 and quartz font backends.
When querying the intersection of a rectangle with the clip region, the
result only depends upon the region extents so we do not need to perform
an expensive region-region intersection computation.
Sascha Steinbiss reported a bug where the PDF backend was reading beyond
the end of the glyph array:
http://lists.cairographics.org/archives/cairo/2008-December/015976.html.
It transpires that in the early glyph culling in the gstate we were
not updating the clusters to skip culled glyphs.
Otherwise this may leads to an invalid memory access to r.
Fixes: Bug 18588 - XCB backend fails with missing render.
https://bugs.freedesktop.org/show_bug.cgi?id=18588
Signed-off-by: Julien Danjou <julien@danjou.info>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The pattern could be stack allocated so we can't take a reference to it.
Some testing of quartz shows that it doesn't deal with malloc failure particularily
well. In the best case CGFunctionCreate returns NULL, in the worst case it just crashes.
Quartz does seem to be able to handle a NULL CGFunctionRef, so returning NULL if
we fail to copy the pattern avoids complicating the code to deal with
propagating the failure and shouldn't cause any additional crashes.
Based on a patch by Paolo Bonzini.
As part of this avoid using cairo_pattern_get_matrix() because it requires a
'cairo_pattern_t *' instead of 'const cairo_pattern *'
Also, make a copy of the pattern before pasing it in to cairo_set_source()
Repeat should be handled using MOD instead of '%' so that negative numbers
are handled as expected. E.g. -1 mod 600 = 599, not 495 as the '%' operator
gives. This was causing https://bugzilla.mozilla.org/show_bug.cgi?id=466258
Patch from Robert O'Callahan
This speeds up the mask generation step in cairo_fill() for the image
surface by up to 10x in especially favourable cases.
image-rgba twin-800 7757.80 0.20% -> 749.41 0.29%: 10.36x speedup
image-rgba spiral-diag-pixalign-nonzero-fill-512 15.16 0.44% -> 3.45 8.80%: 5.54x speedup
More typical simple non-rectilinear geometries are sped up by 30-50%.
This patch does not affect any stroking operations or any fill
operations of pixel aligned rectilinear geometries; those are still
rendered using trapezoids.
This implementation first produces an A8 alpha mask and then
pixman_image_composites the result to the destination with the source.
Clipping is handled by pixman when it is region clipping or by
cairo-surface-fallback when it is something more complex.
Imports a new polygon scan converter implementation from the
repository at
http://cgit.freedesktop.org/~joonas/glitter-paths/
Glitter paths is a stand alone polygon rasteriser derived from David
Turner's reimplementation of Tor Anderssons's 15x17 supersampling
rasteriser from the Apparition graphics library. The main new feature
in this implementation is cheaply choosing per-scan line between doing
fully analytical coverage computation for an entire row at a time
vs. using a supersampling approach.
A surface will have the chance to use span rendering at cairo_fill()
time by creating a renderer for a specific combination of
pattern/dst/op before the path is scan converted. The protocol is to
first call check_span_renderer() to see if the surface wants to render
with spans and then later call create_span_renderer() to create the
renderer for real once the extents of the path are known.
No backends have an implementation yet.
A cairo_span_renderer_t implementation can be provided by a surface if
it wants to render paths as horizontal spans of the alpha component of
a mask. Its job is to composite a source pattern to the destination
surface when given spans of alpha coverage for a row while taking care
of backend specific clipping.
A cairo_scan_converter_t takes edges of a flattened path and generates
spans for a span renderer to render.
A cairo_composite_rectangles_t contains the coordinates of rectangular
windows into each of the source pattern, mask, clip and destination
surface containing the pixels that will combine in a compositing
operation. The idea is to have a uniform way to represent all the
translations involved rather than overloading parameters like src_x/y,
dst_x/y, etc., sometimes with different incompatible meanings across
functions.
