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.
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.
As a result of the changes to improve the status checking,
_cairo_type2_charstrings_init() was failing due to the failure
status returned when the font->output stream is destroyed.
This is because _cairo_type2_charstrings_init() does not
create an output stream.
Fix this by initializing font->output to NULL and only
destroy it if not NULL.
Thanks to Solaris-using Brian Cameron for pointing out that our
shell scripts are bash-specific. We'd be glad if someone cared to
rewrite them to not require bash, but for now let's have truth in
advertising at least.
Put the glyph names in the Encoding array the same as is done for
Type 1 and Type42 fonts.
Acroread and Evince are still unable to correctly extract the text
after conversion with ps2pdf. However examining the pdf file shows
the glyph names are correct so this is probably a limitation of
Acroread and Evince.
7 quartz/argb32/similar tests were showing failures due to
random bits being set. The problem turned out to be that the
initial test surface was not cleared before the similar surface
was created by push_group. The problem behaviour is more obvious
if you run the tests with MallocScribble=1.
Fix this by calling memset after bitmap allocation; the multiplication
here cannot overflow since we already checked that in malloc_ab.
The implementation of EXTEND_NONE was not filling areas outside
the image with rgba(0,0,0,0). This showed up on the operator-source
test, the fix makes the quartz and image renderings identical.
This reverts commit 2fd50a7897.
Spoke too soon, quartz doesn't like creating those 0x0
images; while the tests pass, its putting warnings in the logs.
Reverting to make a better fix.
Some tests, like invalid-matrix, generate a 0x0 bitmap; in
the quartz backend this caused a nil surface to be returned,
whereas the tests expect a quartz surface. Other surfaces
return a backend-specific surface with a zero-sized bitmap,
quartz should do the same.
Fixes the tests ft-font-create-for-ft-face, get-and-set,
get-clip, invalid-matrix, line-width-zero,
select-font-no-show-text, solid-pattern-cache-stress,
surface-finish-twice, and text-cache-crash.
All the copied data buffers except the first one weren't completely
initialized (num_ops and num_points). That was the cause of the failure
of some vector surface tests, like random-intersections.
When emitting combined stroke and fill, cairo SVG backend was using the opacity
two times, instead of using fill-opacity and stroke-opacity, leading to
incorrect output.
I've updated the mask test reference images for the SVG output, since it seems
there's a bug in librsvg when fill-opacity is used in the mask image.
I've checked the SVG output with batik, and it looks fine.
