In the midst of porting 5eec3e378a I failed
to include the pad in the floor() and ceil() which introduces two
potential off-by-one errors into each dimension of the region of interest
of the source surface.
Sigh - finding a crasher in xlib seemed too good to be true. And it was.
The bug is due to the coupling of the XCloseDisplay with the user_data on
the source surface.
This was an externally trigger XCloseDisplay whilst the user had live
surfaces, so I consider this a gross application bug and therefore does
not require graceful handling within cairo-xlib. However, I'm willing to
listen to reason...
Resolve the seemingly conflicting two paragraphs that instruct the writer
of a user-font on when to allocate the glyphs array during text_to_glyphs,
so that it is consistent with itself and the code. In particular, I could
find no indication in the code that num_glyphs is preset to -1 (it should
be a user parameter reflecting the number of entries in the supplied glyph
buffer) and the callback must allocate the array using
cairo_glyph_allocate().
Whilst investigating:
Bug 7360 painting huge surfaces fails
https://bugs.freedesktop.org/show_bug.cgi?id=7360
I found a particular combination of operations that cause a crash within
xlib, so I'm committing the test for posterity.
With the reintroduction of Carl Worth's and Owen Taylor's work to expand
pattern extents as necessary to include extra samples due to the filter
radius, we expect filter-bilinear-extents to PASS. This patch series is
important as it factors out our assumptions about filter radius into a
single function and cleans up the code in its wake.
However, since the external PS/PDF renderers do not necessarily use the same
filter as cairo (and currently they only use NEAREST due to lack of
/Interpolate emission in those backends) we can expect differences in test
output. So add the respective reference images to capture current
expectations and to highlight future changes.
Fixes bugs:
Bug 15349 - bad clipping with EXTEND_NONE
[https://bugs.freedesktop.org/show_bug.cgi?id=15349],
Bug 15367 -Improve filtering handling in cairo-pattern.c
[https://bugs.freedesktop.org/show_bug.cgi?id=15367]
Factor out common filter analysis code from _cairo_pattern_get_extents()
so that we can share it with _cairo_pattern_acquire_surface_for_surface()
as well. During the analysis of the filter determine whether the pattern
matrix maps source pixels exactly onto destination pixels and if so convert
the filter to NEAREST - generalising the existing conversion to NEAREST.
(Patch ported to master by Chris Wilson, all bugs are his.)
This fixes the filter-bilinear-extents test case and the
related bug entry:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
Though there are still differences in the PDF and PostScript
backends, (primarily because we can't capture cairo's filter
modes in those file formats).
Restrict the area we acquire from the source image to the bounds of
the source image, even when we have an identity matrix. This handles
circumstances where the pattern extents may be enlarged due to
filtering, for example when applying a bilinear filter.
This patch replaces the open-coded rectangle intersection which has
already proven itself to be a source of bugs.
(Patch ported to master by Chris Wilson, all bugs are his.)
Remove instances (abuses) of calling _cairo_pattern_acquire_surface() on
a known-surface-pattern with a hack to say "give me the entire surface".
If you know you just want the entire surface as an image surface, that
can be done more simply.
(Split from original patch on
https://bugs.freedesktop.org/attachment.cgi?id=15703, by Chris Wilson -
as usual all bugs are his.)
First, explicitly set the filter mode to BILINEAR in case the default should
ever change. And then draw a second pattern with extents that in theory
are larger than the source surface in order to test handling of acquiring
out-of-bounds extents.
As we use cairo to convert SVG files back to an image, that process is
dependent upon changes within our library and so we cannot skip the
conversion if the SVG file happens to match a previous run. Fortunately,
librsvg is quick enough that this is not a major issue.
I wonder whether merely fixing a compile error in glitz will do anything
towards its utility... Anyway fix the missing comma as reported by
Shunichi Fuji and correct the asserts.
Add the performance test case to compare the speed of filling a rounded
rectangle (one with camphered corners) as opposed to an ordinary
rectangle. Since the majority of the pixels are identical, ideally the two
cases would take similar times (modulo the additional overhead in the more
complex path).
_surfaces_compatible in cairo-xlib-surface returns true for surfaces with
different xrender_format when each has the same depth and no (NULL)
visual.
Common picture formats will not have the same depth, but
it is possible to create a surface with a non-standard xrender_format
having the same depth as another xrender_format with
cairo_xlib_surface_create_with_xrender_format.
Both cairo_xlib_surface_create_with_xrender_format and
_cairo_xlib_surface_create_similar_with_format create surfaces with no
visual.
The same issue exists in the xcb backend.
Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=16564.
Previously, the SVG backend would rash when new operators were added to
cairo.h, now it returns UNSUPPORTED.
Also unsupported operators can now be set as NULL, so image fallbacks can
be used properly.
Should use fallbacks instead of color-dodge for CAIRO_OPERATOR_STURATE?
Because we can independently set either the device scale or the device
offset, we need to be careful and recompute the inverse rather than simply
assuming that the original contents of the device transform is identity.
Fixes regression https://bugs.launchpad.net/inkscape/+bug/234546.
For this we extend the boilerplate get_image() routines to extract a
single page out of a paginated document and then proceed to manually
check each page of the fallback-resolution test.
(Well that's the theory, in practice SVG doesn't support multiple pages
and so we just generate a new surface for each resolution. But the
infrastructure is in place so that we can automate other tests,
e.g. test/multi-pages.)
A few tests explicitly checked whether the "ps" or "svg" target was
enabled and this broke because of the name change. So fixup, to run
the generic test if either PS or SVG target is enabled as appropriate.
A little bit of sleep and reflection suggested that the use of
device_offset_[xy] was confusing and clone_offset_[xy] more consistent
with the function naming.
If the operator is unbounded, then its area of effect extends beyond
the definition of the mask by the trapezoids and so we must always perform
the image composition.
Fixes test/operator*.
In paint and show_glyphs, the compositing operator was not emitted at all.
In mask, the operator was also emitted for the mask itself, which is
wrong.
SVG clear and source differ from cairo as it also affects the
destination if the source pixel are completely transparent. We need to emit
an additional clip-to-self property.
Librsvg does not support clip-to-self, so it renders the SVG
test outputs incorrectly.
This patch also remove a lot of useless spaces in the style property
strings (I know, this should go in another commit).
Previously the rule for clone_similar() was that the returned surface
had exactly the same size as the original, but only the contents within
the region of interest needed to be copied. This caused failures for very
large images in the xlib-backend (see test/large-source).
The obvious solution to allow cloning only the region of interest seemed
to be to simply set the device offset on the cloned surface. However, this
fails as a) nothing respects the device offset on the surface at that
layer in the compositing stack and b) possibly returning references to the
original source surface provides further confusion by mixing in another
source of device offset.
The second method was to add extra out parameters so that the
device offset could be returned separately and, for example, mixed into
the pattern matrix. Not as elegant, a couple of extra warts to the
interface, but it works - one less XFAIL...
We use the full matrix in hash computation, but only compare the
non-translation items in equality check. This is no bug though,
as we set the ctm translation components of a scaled font to zero
explicitly. But the change makes the hash and equal functions
consistent, which is good.
