[cairo] GSoC: Scan converting rasteriser update

[Bill Spitzak]

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.

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.

In fact there is no reason to *ever* return UNSUPPORTED. Instead the 
backend just directly calls the correct fallback function. Or even 
better it can be a table of calls, and the backend just leaves that 
entry pointing at the fallback function. This also allows most Cairo api 
to jump directly to the backend, as the return values can be the same.

-- 
Bill Spitzak, Senior Software Engineer
The Foundry, 618 Hampton Drive, Venice, CA, 90291, USA
Tel: +1 310 399-4555 * Fax: +1 310 450-4516 * Web: www.thefoundry.co.uk
The Foundry Visionmongers Ltd * Registered in England and Wales No: 4642027