The interpolation range of repeating radial gradients can safely be
reflected around any integer (previously 0), but for reflect-extended
radial gradients can only be reflected around odd integers if the
appearance is to be the same, thus reflecting around 1 is correct for both.
Fixes radial-gradient.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=29125
To be consistent with _cairo_gstate_clip_extents, the context's clip
should be intersected with the target surface extents (instead of only
using them when there is no clip).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
If the gstate clip in _cairo_gstate_int_clip_extents() has all_clipped
set (and path NULL), then it returns the gstate target extents instead of
an empty rectangle. If the target is infinite, then it says the clip is
unbounded.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=29124
Tested-by test/get-clip
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Remove the hack of using the xlib surface to do glyph rendering and use
the new interface introduced with Qt4.7, or else fallback to image
rendering with freetype.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[2 files changed, 35 insertions(+), 140 deletions(-) \o/]
This is path is slightly peculiar in that it explicitly avoid the
intermediate mask and the geometry is not pre-clipped.
This in conjunction with the previous commit fixes:
Clip doesn't work for text
https://bugs.freedesktop.org/show_bug.cgi?id=29008
which is captured in test/partial-clip-text.
No point in passing in a column of zeroes that we multiply by zero, or
the row that we drop on the floor. We could do even better by just
passing in a 3x2, at the expense of adding a language version
dependency (or just pass in 2 vectors).
No significant performance difference.
What we want to use is size_t, but we don't want the implied POSIX
dependency. However, POSIX does say that size_t is an unsigned integer
that is no longer than a long, so it would appear safe to use an
unsigned long as a replacement. Safer at least than unsigned int.
Currently wether internal glew is built is dependant on wether the
tarball in use was built with internal glew or not. And that's not how
it should be.
This is an attempt to fix the broken situation we've been in where
automake links libcairo.la with c++ because it might potentially maybe
include C++ files.
Those potential files only exist in Chris' throwaway backends (skia, qt)
and the BeOS backend, so for 99.99% of cases, these backends are not
needed and linking with c++ is overkill. Also, no one wants to have
libcairo.so link to libstdc++.
This patch fixes that in mutliple steps:
1) Add build infrastructure to distinguish between C and C++ backends.
This is done by allowing to specify backend_sources as well as
backend_cxx_sources variables in Makefile.sources.
2) Optionally build a libcairo_cxx.la noinst library
This intermediate library is built for C++ backends only and therefor
linked using c++. It is then linked into the final libcairo.la. This
does not require c++, so the linking of libcairo.la is done with cc.
This also works around various weirdnesses that the current build system
exposes, where it assumes cisms when in fact using c++ semantics, like
not detecting c++ properly or:
https://bugzilla.redhat.com/show_bug.cgi?id=606523
Add general docs and document acquire/release. I'm not happy with the
documentation yet. In particular, I have 2 issues:
1) The threading guarantees Cairo provides are missing.
2) There's no docs on which Cairo functions do acquire devices.
I guess I'll have to fix them later.
I did this manually so I could review the docs at the same time.
If anyone finds typos or other mistakes I did, please complain to me (or
better: fix them).
Use cairo_drm_xr_sources/headers for the drm_xr stuff. This makes it
work correctly in gtk-doc instead of conditionally adding it to
cairo_drm_sources/headers.
