[cairo] filters/image processing

[Carl Worth]

On Fri, 24 Mar 2006 19:03:57 -0500, MenTaLguY wrote:
> Hmm.  After some consideration, I think the existing
> cairo_pattern_{set,get}_filter stuff is totally orthogonal to what we
> really want for SVG filters and should be left as-is.
> 
> How about "filters" as composed patterns?  I suspect that shouldn't
> require any changes to existing APIs, at least not external ones.
> 
> For example (not the best function name, but it'll do for discussion):
> 
>  cairo_pattern_t *cairo_filter_gaussian_blur(cairo_pattern_t *source, 
>                                              double radius);

Can I convince you that I already had an email all composed that said
exactly the same thing? I decided pipeline-ability meant we had to
have patterns in and patterns out. I started with:

	cairo_pattern_create_filtered_gaussian_blur

rejected that and ended up with:

	cairo_filter_gaussian_blur

exactly as above.

The name clash with the existing cairo_filter_t is rather unfortunate,
but I don't see a good answer for that yet. We also lose the "create"
name to pair with cairo_pattern_destroy, but we can just expect users
of the filter stuff to learn that[*]

> I think the output of such filter patterns should generally be infinite
> (source data not supplied by the source patterns(s) would be assumed to
> be transparent black, or whatever makes the most sense for the
> particular filter).

Yes, patterns are all defined as infinite sources. And any pattern,
(including intermediate patterns in a big filter graph), can still
have cairo_pattern_set_extend applied for finer control of this.

So This is all looking pretty good to me.

But there is at least one place I would like to capture an entire
filter graph without requiring the user to have a handle on the source
patterns for the graph. Specifically, what I want to add is a
cairo_set_mask_filter function that allows the user to control what
kinds of filtering happens to the implicit mask patterns created by
things like cairo_stroke, cairo_fill, or cairo_show_text/glyphs.

This is the kind of thing one would want for doing drop shadows or for
doing "soft" strokes/fills.

Oh, here's a stupid idea. What if we did something like:

	cairo_filter_t
	cairo_filter_allocate (cairo_pattern_t *pattern);

Which would allocate a new filter ID to represent the filter graph
represented by pattern. And then maybe we could provide some
pre-defined dummy source patterns so that a resulting filter ID could
be passed to cairo_set_filter or cairo_set_mask_filter and the correct
source or mask would be fed into the filter graph where appropriate,
(while other explicit patterns might feed in at other points).

If nothing else, this would alleviate the name clash by actually
proving a means to emulate the existing cairo_filter_t values
precisely.

Is that completely crazy?

-Carl

[*] I'm simultaneously turning down API consistency and hurting my
chances at creating the longest function name to ever appear in a free
software library. I'm definitely having an off day today.
-------------- 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/20060324/db577044/attachment.pgp