[cairo] [PATCH] Path clipping

[Carl Worth]

On Tue, 14 Jun 2005 12:14:25 -0400, Kristian Høgsberg wrote:
> Okay, here's a new patch.

Thanks. This is much easier to read. It's a great improvement.

> I decided to keep _cairo_surface_set_clip_path(),

Another way to unify things would be to push the recursion down into
the backend, but I don't know if that would even be worth doing.

Similarly, you might also think about adding
surface->backend->reset_clip for _cairo_surface_reset_clip. That would
also eliminate the confusion I had from seeing the outer call to
surface->backend->intersect_clip_path with NULL in
_cairo_surface_set_clip_path. But again, I'm not sure it's worth it to
add another backend function here, (and the behavior for a NULL path
is documented now). So this is your call.

> Another thing; I didn't do the cairo_clip_t union.

That's fine.

The only thing I noticed in the patch is a small thing missing that
should make a big difference. _cairo_gstate_init needs:

	gstate->clip.mode = _cairo_surface_get_clip_mode (target);

And without that, some of the tests fail some assertion.

In general, I don't love the way that gstate is now mucking with the
initialization of two extra levels of nested structures on its own
(gstate->clip and gstate->clip.path). Though most of the clip.path
manipulation is actually abstracted into independent _cairo_clip_path
functions. But don't worry about fixing this, as I just found a patch
that I had misplaced for cleaning up _cairo_gstate_init_copy, and
fixing this will work well into that patch.

Beyond that, we need to come up with a better way for testing PDF
output. My initial version of the pdf-surface test drew just a smiley
face since that's pretty easy to visually verify. And the point of
that test was just to verify that we could output _something_ in PDF,
(eg. without crashing and without producing empty output).

This patch adds another page to the output of pdf-surface which tests
significantly more complex capabilities of the PDF backend. Perhaps
this should be in a new test instead? And the results aren't easy to
verify visually. Shall we make the test suite depend on poppler so
that we can do reference-image-based verification of the PDF output?
(Though the circular dependency that would introduce into the test
suite could be a nuisance.)

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050614/a0a12d93/attachment.pgp