Move the predicate for starting a new glyph elt into a macro so that it
can be shared between _cairo_xlib_surface_emit_glyphs() and
_emit_glyph_chunks() without code duplication.
_cairo_xcb_surface_is_similar() is currently only used by the pattern
cache to determine whether to keep the surface in the solid color cache.
This is fundamentally broken without hooking into Display closure as it
keeps a reference to an expired picture. So in order to prevent spurious
application crashes, disable the caching for xcb.
As reported by Damian Frank:
"I ran into a hitch with the Makefile.win32 infrastructure. It uses -MD and
-LD when linking regardless of the config, but it should be using -MDd and
-LDd for the debug config. I believe both the Makefile.win32.common and
src/Makefile.win32 files include erroneous declarations. This produces
warnings at link time about a mismatch when linking against properly created
debug libs (for instance, I had a zlib built as "LIB ASM Debug" that linked
properly against the debug runtime).
This problem applies to pixman too; can you pass this along to the
maintainer?"
Would be delighted to if someone commits a fix to pixman reading this
commit message.
This reverts commit 0eb0c26474.
The change was too drastic and overlooked some subleties of the old
code, but the main reason for the revert is that it introduced an
ugly duplicated glyph flush block. I'm working on a more incremental
fix.
These are the versions available on RHEL5 (two years old now), and
we know cairo works with them. There's evidence that our build system
does not work with older automake, and we've been requiring autoconf 2.58
but no one ever tested 2.58 with the new build system. It's very likely
that 2.58 doesn't work and needs some macro backporting. In any case,
no one reported that they have 2.58 when I asked on the list.
show-glyphs-many is triggering an assertion failure within xlib. The cause
appears to be that we are submitting an overlong request.
Reviewing the code and comparing with libXrender/src/Glyph.c I found two
points to address.
1. When encountering the first 2-byte, or 4-byte glyph and thus triggering
the recalculation of the current request_size, we did not check that there
was enough room for the expanded request. In case there is not, we need to
emit the current request (before expansion) and reset.
2. Subtleties in how XRenderCompositeText* constructs the binary protocol
buffer require that xGlyphElts are aligned to 32-bit boundaries and that
it inserts an additional xGlyphElt every 252 glyphs when width==1 or
every 254 glyphs for width==2 || width==4. Thus we need to explicitly
compute how many bytes would be required to add this glyph in accordance
with the above.
Considering the complexity (and apparent fragility since we require tight
coupling to XRender) of the code, I'm sure there are more bugs to be
found.
Within _cairo_xlib_surface_emit_glyphs() there are a number of
complications to do with packing as many glyphs as possible into a
single XRenderCompositeGlyph*() call. Essentially these consist of
choosing the right function and packing for the current glyphs, describing
runs of glyphs and ensuring that we do not exceed the maximum request size
within a single call. So we add to the test case we an attempt to show 64k
2-byte glyphs and an attempt to mix 64k 1-byte and 2-byte glyphs, with the
change-over point chosen to overflow the maximum request size, should
_cairo_xlib_surface_emit_glyphs() naively resize the current request.
Moral of this story is bugs cluster. If we made a mistake, especially in a
complicated bit of code that is interfacing with another library, then we
are likely to make a similar mistake in future. Disabling this test hid a
regression between 1.4 and 1.6.
I swear that when I said that it was a rounding error, I was looking at an
image where the squares were overlapping the lines and had a listing of
all the coordinates used. However, the current output on all the machines
I have to hand is correct so I believe the underlying bug to be fixed.
Update the reference images for the external renderers because (a) GS
exhibits the same bug cairo had and (b) librvsg/PDF do not use NEAREST
when applying surface patterns, so the squares are blurred as a result.
Avoid requiring (an absent!) rgb24 ref image by using an opaque grey
background. Confirm the reference image is identical to the old one
(modulo the background change) using GIMP.
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.
