The problem is _cairo_recording_surface_replay_and_create_regions()
stores the cairo_recording_region_type_t in the same structure as the
recording commands. This does not work well when the recording surface
is used as source by multiple surfaces
Fix this by moving the cairo_recording_region_type_t into a separate
struct cairo_recording_regions_array_t. This struct is stored in a
list that allows multiple create regions results to be store in the
surface.
The new function _cairo_recording_surface_region_array_attach() is
used to create a new cairo_recording_regions_array_t, attach it to the
recording surface and return a unique region id.
The _cairo_recording_surface_replay_and_create_regions() and
_cairo_recording_surface_replay_region() functions use this region id
to identify the cairo_recording_regions_array_t.
To handle nested recording surfaces, when replaying a recording, the
region id is passed to the target as an extra parameter in the surface
pattern. The wrapper surface makes a temporary copy of the pattern to
ensure the snapshot pattern in the recording surface is not modified.
cairo_recording_regions_array_t has a reference count so the target
can hold on to the cairo_recording_regions_array_t after the paginated
surface has called _cairo_recording_surface_region_array_remove().
There is a bug in the recording surface where if one recording surface
is used as the same source on different paginated targets that support
fine grained fallbacks, the output may be incorrect because the
analysis results of a previous target are re-used on another target.
WINVER and _WIN32_WINNT macros were defined in each source files and
headers that were including <windows.h>. However, because DirectWrite
requires new Windows API, some files included <windows.h> without the
version macros. This inconsistency sometimes caused troubles.
Define the version macros in meson.build.
The base image has 16 bits per channel, with colors that do not
have an exact corresponding 8 bit representation. The reference
image uses 8bpc, like the rgb24/argb32 formatted images which
the test outputs.
Before this change, images with RGB30, RGB96F, and RGBA128F formats
would have been given garbage xrender formats; now such images
use the fallback path and are converted to formats with an xrender
equivalent.
`_cairo_status_set_error` was using `_cairo_atomic_int_cmpxchg` to set
a `cairo_status_t` variable by casting a `cairo_status_t*` to
`cairo_atomic_int_t*`. `cairo_atomic_int` has a generic implementation
which is using a mutex. In the implementation, `cairo_atomic_int_t`
was typedef-ed to `cairo_atomic_intptr_t`. In a typical 64bit system,
cairo_atomic_intptr_t is 64bit and cairo_status_t is 32bit,
_cairo_status_set_error didn't work as expected.
Define `cairo_atomic_int_t` as an alias of `int`.
Added an assertion in `_cairo_status_set_error` to ensure
that `*err` has the same size with `cairo_atomic_int_t`.
Fixescairo/cairo#606
GeometryRecorder class was calling _controlfp_s with MCW_PC to reset
the floating point precision to default. However, MCW_PC isn't
supported for ARM or x64 platforms. It reports an assertion failure
for them. And, Cairo isn't changing the MCW_PC setting. Removed the
calls. Also, removed `GetFixedX` and `GetFixedY` methods because they
called only `_cairo_fixed_from_double`.
Fixescairo/cairo#566
Scaled font creation may fail if the font size is very large on
win32. But, don't leave the font face in an error state in such
case.
Fixescairo/cairo#607
There was an assertion in
`_cairo_recording_surface_acquire_source_image` to ensure the surface
isn't unbounded. However, this assertion was failing for
`record-paint` test on Windows.
Removed the assertion and return `CAIRO_INT_STATUS_UNSUPPORTED` if the
surface is unbounded.
Fixescairo/cairo#619
height (instead of integers).
Both cairo_pdf_surface_set_size and cairo_ps_surface_set_size passed on
their width and height arguments (of type double) directly to
_cairo_paginated_surface_set_size(cairo_paginated_surface_t*, int, int),
so the width and height were truncated.
A small part of the surface was then inaccessible for drawing (stripes
on the right and bottom of the surface).
This fixes that.
This svg
<svg /><path stroke-dasharray=""fill="url(# "id=""/>
Lead to two memory leaks like the following:
98 bytes in 98 blocks are definitely lost in loss record 2 of 11
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4EB8789: strdup (strdup.c:42)
by 0x493C450: save_graphics_state (cairo-svg-glyph-render.c:2894)
This happened because the value of gs->dash_array was replaced without
freeing the previous value. This commit adds the missing free and fixes
the leak.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=54830
Signed-off-by: Uli Schlachter <psychon@znc.in>
