Test handling of source clipping with an image - principally to check
handling of mime types and zero-copy image snapshotting in the vector
surfaces and ensure that they work with subsurface patterns as well.
Add tests to ensure that modifications to the subsurface via the
original surface are tracked by the subsurface, i.e. that any snapshots
are detached upon modification of the parent as well as modification of
itself and vice versa.
Carefully handle subsurfaces of a recording surface through the analysis
and paginated surfaces so that we can generate a native pattern for the
vector backends, demonstrated by the PostScript backend.
Nothing remarkable, just a lot of bookkeeping to track the wrapped
surface types and to apply the correct offsets when generating the
subsurface pattern.
After a renewed discussion, it was pointed out that the API in Cairo was
not restrictive and by using doubles we would be consisted with the rest
of the API. Thus prompting the name change to
cairo_surface_create_for_rectangle()
similar to cairo_rectangle().
And document the public API.
Use a similar surface to create an equivalent backing surface for
any backend, thus enabling the test to run against any target.
The comment about forcing fallbacks has long since been false.
The issue being that as the on-stack data is being referenced via a
zero-copy snapshot outside of the functions scope as the surface is only
finished and the source written long after the draw() returns. The
correct procedure is that the user must call cairo_surface_finish()
prior to any surface becoming inaccessible. In this case, this triggers
the snapshot to preserve a copy of the data whilst it is still valid.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
cu found a bug when using clipping and fills with the image backend, but
it turns out to be the lost sign bug afflicting everything...
To trigger the bug requires evaluating the clip surface prior to using
in with _cairo_clip_combine_with_surface(). Which is taken along a
particular path when using a clip mask with non-pixel geometry on image,
but more easily hit by the fallback code.
Reported-by: <cairouser@yahoo.com>
This should exercise a bug found by Jeff Muizelaar that
cairo-surface-clipper was mistakenly thinking that clip operations on a
second context was a no-op as the topmost clip path matched that of the
previous context.
A push/pop is an implicit save/restore, so a clip applied inside the
group is temporary, whereas a clip applied outside affects both the
geometry inside *and* the application of the group when painted. So
reset the clip afterwards to get the desired behaviour.
We were exposing the actual value of CAIRO_FORMAT_INVALID
through API functions already, so it makes sense to just
go ahead and put it in the cairo_format_t enum.
Franz Schmid reported a regression in 1.9.6 when downscaling
and using EXTEND_REPEAT for an image surface pattern. This
patch adds such tests for every extend mode.
