The API should preserve the precision across the public interface so that
the user is able to retrieve the co-ordinates that he used to construct
the path. However since we transform the path to a 24.8 fixed-point
internal represent we currently incur a precision-loss - the affects of
which can be seen in the miter-precision test case for example. It is
planned to move to keeping the path as doubles until the backend
explicitly requests the fixed-point coodinates (and some backends, e.g.
pdf, might only ever use the doubles). Then, barring rounding errors
during path transformations, we should be able to return the exact path
the user set (under an identity CTM, of course ;-).
Frequently to push an object onto the stack all we need is to simply
perform the struct copy - so inline it and only call the out-of-line
function if we need to enlarge the stack.
The relational comparison operators can now compare strings vs names
by content as well as performing automatic type promotions on the
numeric types. For other types relational comparisons succeeed
only if the values compare equal according to the eq operator, and
put the interpreter into a type-error state otherwise.
The eq operator would only work for some types and put the
interpreter in an error state if passed objects it didn't
know how to compare. It would also not compare strings
by value nor allow strings to be compared to names.
This patch makes any two objects comparable.
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 an issue with glyph culling,
http://lists.cairographics.org/archives/cairo/2008-December/015976.html,
whereby we failed to update the text clusters upon culling the glyphs in
the gstate and proceeded to read beyond the end of the glyph array in the
PDF backend. This test case setups a similar condition as reported, by
trying to write a wide string into a small box.
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.
