| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
The glibc versions are slow in utf8 locales.
|
|
Whilst creating the xlib surface wrapper for gradient Pictures, the
corresponding attributes require ComponentAlpha disabled.
|
|
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.
|
|
Peter Clifton spotted that we failed to properly wrap
_cairo_int64_32_div() for systems without a native 64 bit type.
|
|
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
|
|
The new name is more descriptive than the rather opaque meta surface.
Discussed with vigour on the mailing list and #cairo:
http://lists.cairographics.org/archives/cairo/2009-July/017571.html
|
|
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.
|
|
Or perhaps, more importantly, when the contents are left unmodified.
|
|
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 ade55037ffa596b690c6a1051394589f76eb1f48 and quick-fixed
by 79190d89853958ee8252440d35a662fabf122afd. 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.
|
|
_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.
|
|
Avoid pulling in the real pthread library if the application is single
threaded and not using pthreads, by linking against pthread-stubs
instead.
|
|
Use libatomic-ops-dev in preference to mutex-based atomics, if we do not
have the builtin atomic intrinsics available.
|
|
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.
|
|
Bug 24240 acroread prints error message when printing
|
|
Bug 24240 first char missing when printing a PDF.
|
|
XCB avoids the dreaded abort on XError mechanism by forcing the client
to perform deferred error checking. So do so. This allows us to combine
the fire-and-forget rendering model with accurate error checking,
without killing the client or mixing our errors with theirs.
XCB for the win!
|
|
|
|
Bug 24213
|
|
Replaying a meta surface can be achieved by using it as a source for a
cairo_paint() so exporting a separate API is unnecesary and confusing.
So after consulting Chris and Carl, we decided to remove the function
again.
|
|
Add bread crumbs in the form of NoOperations that can be parsed by
xtrace and very useful when debugging protocol/server errors.
|
|
When scanning for collinear right edges, we need to check that we do not
go beyond the end of the array.
|
|
Fixing omission in caa9eed4646e78a62ffb49d9c4f48c0b351c7a7f
|
|
|
|
Patch originally by Mark Kettenis
|
|
Some PS viewers like gv use the label in the %PageMedia DSC comment as
the displayed page size.
The page names and sizes were obtained from the list at:
http://www.gnu.org/software/gv/manual/html_node/Paper-Keywords-and-paper-size-in-points.html
|
|
Provide default DocumentMedia and PageMedia DSC comments if the user
does not specify them using cairo_ps_surface_dsc_comment(). This is
required so that PostScript viewers such as gv use the correct page
size.
|
|
When an image cannot be expressed as masks, its data cannot be used in
an XImage. In that case, we use pixman to copy the image to the desired
format.
|
|
Return FALSE when the pixman format does not support ARGB masks. In
particular, return FALSE for YUV formats.
|
|
Gah, more important than the whitespace was the reversal of is_clear...
|
|
Whitespace spam.
|
|
Simplifies code and ensures other users of that function don't run into
the same bug.
|
|
Benjamin Otte pointed out the error of my ways that a clear on a
cairo_image_surface_create_for_data() was not working. This is because I
modified the image surface to skip clears when it knows the target data
has been cleared. This flag must be reset when the user interacts with
the surface, such as providing the initial surface data.
|
|
If we cannot find the correct visual for the fbconfig, return an error
instead of crashing. The difference is subtle, granted.
|
|
it was wrapping code required for non windows fonts.
|
|
|
|
To better support creating EMF files with the win32-printing surface,
allow a GDI CTM with scale < 1 to be used.
http://lists.cairographics.org/archives/cairo/2009-September/018110.html
|
|
|
|
|
|
|
