At the end of the private dictionary a new line is appended so that
the trailing zeros will not exceed 80 columns. In hex mode (used for
PS embedding) extra white space is harmless as it is ignored when
parsing the ascii hex encoded data. But in binary mode (used for PDF
embedding) the new line must not be added as it corrupts the binary
data.
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/419143
Both _cairo_xlib_call_close_display_hooks and _cairo_xlib_screen_destroy
invoke _cairo_xlib_screen_close_display, which frees all the cached
GCs, but (if HAS_ATOMIC_OPS is undefined) doesn't mark them as freed,
thus freeing them agin upon the second invocation.
The function _cairo_image_surface_create_for_content does not exist.
The correct name of the function is instead _cairo_image_surface_create_with_content.
When the reference point was tirggering _line_exceeds_16_16() and got
adjusted, the code failed to compute the srcX and srcY arguments for the
call to XRenderCompositeTrapezoids() correctly and caused the resulting
source image to be misaligned.
This test fills a slightly rotated surface slightly above the 0 line.
This hits some corner cases in the XRenderComposite path.
I discovered these issues while playing with video rendering onto the
canvas in HTML5 (both Webkit and Mozilla have this problem).
I used CAIRO_ANTIALIAS_NONE and a single-color source in the test to get
rid of aliasing issues in the output images. This makes some issues
slightly less visible, but still fails for all of them. If you want to
get a clearer view, disable it and use romedalen.png instead - it has
the same size as the red surface.
(At least) 3 bugs are at work here:
- if _line_exceeds_16_16() triggers for the reference point, the
source surface will be misaligned.
- the intel driver seems to have an off-by-one bug on my i945 when
positioning the source surface, causing black seams at the top
(not visible in the test unless using romedalen.png) and on the left
of the image.
- My Xvfb fails completely in picture up/download in the xlib-fallback
path.
Only the very first line-to following a move-to can have any
significance if degenerate whilst stroking, so skip all others.
In other words,
0 0 m 0 0 l stroke
produces a capped degenerate path (i.e a dot),
0 0 m 0 0 l 0 0 l stroke
produces the same degenerate stroke, and
0 0 m 0 0 l 1 0 l stroke
produce a horizontal line.
Malte Nuhn reported hitting an assertion:
cairo-path-stroke.c:1816: _cairo_rectilinear_stroker_line_to: Assertion `a->x == b->x || a->y == b->y' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=24797
when stroking an apparently simple path:
0 8.626485 m
0 8.626485 l
5.208333 2.5 l
10.416667 2.5 l
15.625 2.5 l
20.833333 2.5 l
26.041667 2.5 l
31.25 2.5 l
36.458333 2.5 l
41.666667 2.5 l
46.875 2.5 l
52.083333 2.5 l
57.291667 2.5 l
62.5 2.5 l
67.708333 2.5 l
72.916667 2.5 l
78.125 2.5 l
83.333333 2.5 l
88.541667 2.5 l
93.75 2.5 l
98.958333 2.5 l
104.166667 2.5 l
109.375 2.5 l
114.583333 2.5 l
119.791667 2.5 l
125 2.5 l
stroke
which upon reduction becomes:
0.000000 8.625000 m 5.207031 2.500000 l 125.000000 2.500000 l stroke
The bug is that after spotting a repeated line-to we move the previous
end-point without reclassifying the path, hence we miss the
non-rectilinear step.
Bug 24730 -- New: misleading use cases in cairo_scaled_font_text_to_glyphs's docs
http://bugs.freedesktop.org/show_bug.cgi?id=24730
An apparent copy'n'paste error from the code which has to deal with
indirect pointers crept into the documentation for the same functions.
If the pattern is for example a repeating 0x0 image, then treat it as
having zero extents.
This should workaround the bug presented here:
https://bugs.freedesktop.org/show_bug.cgi?id=24693
Attached PDF crashes evince with a Floating point exception
Within our code base we carried a few hacks to utilize the component
alpha capabilities of pixman, whilst not supporting the concept for our
own masks. Thus we were setting it upon the pixman_image_t that we
passed around through code that was blissfully unaware and indeed the
component-alpha property was forgotten (e.g. upgrading glyph masks).
The real issue is that without explicit support that a pattern carries
subpixel masking information, that information is lost when using that
pattern with composite. Again we can look at the example of compositing
a sub-pixel glyph mask onto a remote xlib surface for further failure.
Create a scratch surface that will be initialised as required for
internal use. External surfaces, i.e. those returned to the user, are
cleared as normal.
A nasty surprise whilst profiling is that performing redundant clear
operations is extremely painful. We can mitigate this somewhat by
tracking the cleared state of surfaces and skipping repeated attempts to
clear a surface.
AO_compare_and_swap_full() doesn't have the same semantic as
_cairo_atomic_int_cmpxchg(). The former returns a TRUE on success
FALSE otherwise while the later returns the atomic value.
Previously target device offsets were applied in cairo-surface.c which
could cause bugs when paths were taken as fallbacks, as for example
pointed out by ade55037ff and quick-fixed
by 79190d8985. The quick-fix is now
unnecessary and was removed.
Gah, that was a horrible mistake. It was a flawed hack to create Pixmaps
of the correct depth when cloning patterns for blitting to the xlib
backend. However, it had the nasty side-effect of discarding alpha when
targeting Window surfaces. The correct solution is to simply correct the
Pixmap of the desired depth and render a matching pattern onto the
surface - i.e. a reversal the current acquire -> clone. See the
forthcoming revised xcb backend on how I should have done it originally.
Honour the incoming surface format when we are asked to create a similar
surface with identical content. The goal of
cairo_surface_create_similar() is to create an intermediate with similar
characteristics to the original that can be used in place of the
original and be quick to copy to the original. Matching the format for
the same content, ensures that the blits between the two need only be a
memcpy.
The goal is to create a similar surface with an identical format to
maximise performance in the subsequent blit, e.g. the xlib backend could
make the similar surface with an identical depth and so use the core
protocol, or the image surface could indeed make an identical copy so
that pixman only has to do a fast memcpy. As there is no direct method
to specify such a clone, we ask the backend for a similar surface of
identical content, and trust that the semantics are clear enough for the
intent to obvious.
Otherwise, it was disrupting my attempts to release a snapshot, (since
it doesn't respect CAIRO_TEST_TARGET=" " and not run like most of the
tests do).
Turns out we were passing suncc warning suppression flags to gcc
by mistake since -e<entry point> is actually a valid option for
gcc. This caused the -erroff=E_ENUM_TYPE_MISMATCH_ARG and other
-erroff options to be passed to the linker. In the normal case
of a GNU ld linker this doesn't matter since it ignores bogus
entry points, but the GNU gold linker replaces a bogus entry
point with NULL. This patch makes the CAIRO_CC_TRY_FLAG()
check stricter by testing that the flag doesn't interfere with
linking executables.
_cairo_surface_fallback_paint() attempts to avoid a clipped operation if
we can convert the paint into a fill of the clipmask. However by calling
_cairo_surface_fill() we incur a double application of device offset to
the source, triggering various failures.
Company spotted this and managed to extract an excellent minimal test
case, test/clip-device-offset. This commit fixes that failure.
As noted in the comments we could also compute the pattern extents for
gradients with CAIRO_EXTEND_NONE under certain circumstances, i.e.
radial gradients and device axis aligned linear gradients.
