By enlarging buf_size to ensure the correct alignment of the points
array with the cairo_path_buf_t block, we can efficiently use the
padding bytes to store more ops.
In http://bugs.gentoo.org/show_bug.cgi?id=203282, it was identified that
the cairo_path_buf was causing unaligned accesses (thus generating SIGBUS
on architectures like the SPARC) to its array of points. As we manually
allocate a single block of memory for the cairo_path_buf_t and its
arrays, we must also manually ensure correct alignment - as opposed to
cairo_path_buf_fixed_t for which the compiler automatically aligns the
embedded arrays.
cairo_get_target() returns the original surface passed to
cairo_create(), and not the current destination as required when
testing drawing to the same surface using multiple contexts.
For completeness we also use the group target when creating similar
surfaces within the tests (to check that similar surfaces of similar
surfaces also work).
If the backend does not support fallbacks ie backend->acquire_dest_image
or backend->acquire_source_image is NULL, then return
CAIRO_INT_STATUS_UNSUPPORTED rather than attempt to jump to the NULL
hooks.
To correctly copy a surface onto the destination irrespective of its
content requires the SOURCE operator. Forgetting to do so here causes
uninitialized pixels to be mixed into the result and the failure of
many tests for the similar surface. Oops...
Avoid returning uninitialized variables if we're asked to find the
bounds of an empty path - in which case we just return a rectangle
of zero width and height similar to the empty clip region.
In http://bugs.freedesktop.org/show_bug.cgi?id=13699, Pavel Vozenilek
reports a duplicate define for computing the appropriate length for an
on-stack array. The macro in question, and a few other places, was
performing CAIRO_STACK_BUF_SIZE/sizeof(stack[0]) so we can simplify
them slightly by using a common macro.
The reasoning for that commit was that fonts with bitmap strikes should be
rendered with antialiasing off for those (hopefully) few glyphs that don't
have a bitmap.
However, it turns out, there are fonts that have some, but very few, bitmaps,
and this changed forces non-AA rendering on them. We now support multiple
glyph formats per font in the Xlib backend, so backing this out to let every
glyph render as is. Fontconfig rules can be used to force AA off on a per-font
basis.
This reverts commit 06af5c2891.
We maintain three Xrender glyphsets per scaled font, one for each of A1, A8,
and ARGB32. This is required to correctly support fonts with bitmaps for
some glyphs but not all.
Added a couple of (boolean) env. vars affecting the backend:
CAIRO_DIRECTFB_NO_ACCEL, disables acceleration
CAIRO_DIRECTFB_ARGB_FONT, enables using ARGB fonts instead of A8
Apparently glibc already provides the function:
void malloc_stats (void);
So, like we do for backtrace_symbols(), override the public symbol.
It still is defined as __destructor__ and runs at program finalization.
- Improved performance in case of surface conversion: allocate a shadow buffer that can only grow
- Fixed support for small surfaces (less than 8x8)
- Optimize the blending function according to the surface format
- Added _directfb_categorize_operation(): selects the blitting function according to the transform matrix
- Avoid inverting the matrix when doing a simple StretchBlit()
- Use TextureTriangles() instead of StretchBlit() when scale factors are negative
- Added support for ARGB32 fonts (converted to A8 internally)
- Removed unused functions (flush() and mark_dirty_rectangle())
- Code cosmetics
Avoid checking the gradient type twice. This refactor
also makes it easier to check when the gradient has no stops,
and will make it easier to separate out the different
implementations of EXTEND_REPEAT, REFLECT for linear and
radial gradients.
Boris Zbarsky reported a bug where having zero stops in a
gradient pattern would crash in the quartz surface. This
test checks for that case. Mozilla bug#407104.
This also crashes testing pdf; and the ps, svg surfaces
look suspicious (they reference stops[0]) but I havent
been able to test them yet.
Add ability to use OS/2 APIs instead of C library functions to manage
pixel buffer allocations. This is to work around heap fragmentation.
This implements two wrapper functions which replace _cairo_alloc_abc and
free and when compiled with OS2_USE_PLATFORM_ALLOC the OS/2 functions
DosAllocMem and DosFreeMem will be used for allocation/deallocation.
Also try to minimize the heap when shutting down the cairo library.
