[cairo] GSoC: Scan converting rasteriser update

[Jeff Muizelaar]

On Mon, Oct 06, 2008 at 11:51:49AM -0700, Bill Spitzak wrote:
> Jeff Muizelaar wrote:
> 
> >>I think the idiom is very readable and useful when you grasp it:  a 
> >>function
> >>returning cairo_int_status_t can return UNSUPPORTED and not worry about 
> >>what
> >>happens, while one returning cairo_status_t can't.  That simple, and a 
> >>lot can
> >>be checked using static analysis.
> >
> >That's not really true; you do need to worry about what happens. If you
> >have a backend that doesn't implement fill() you have to implement
> >composite_trapezoids(). composite_trapezoids() certainly isn't the only
> >logical operation to implement fill with, a backend end could, for
> >example, want composite_spans(), composite_flattened_polygon() or
> >composite_non_intersecting_polygon(). We wouldn't want to probe each
> >backend for each of these possible operations. 
> 
> I have to disagree with this. Having the backend call implementations in 
> Cairo would work quite well and would be far simpler and more powerful.

Are you disagreeing with what I said or what Behdad said?

> Cairo can supply multiple fallback functions. In the given example, 
> Cairo might provide fill_using_trapezoids() *and* fill_using_spans(). 
> The backend would "select" the right version to use by calling the 
> correct callback function. There is no "probe", the selection was made 
> when the backend was compiled.

This is what Carl and I are suggesting.

-Jeff