[cairo] GSoC: Scan converting rasteriser update

[Bill Spitzak]

Jeff Muizelaar wrote:
> 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

Nevermind, I think we are agreeing. I misread your paragraph.

-- 
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