[cairo] GSoC: Scan converting rasteriser update
spitzak at thefoundry.co.uk
Mon Oct 6 12:12:01 PDT 2008
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
>>>> returning cairo_int_status_t can return UNSUPPORTED and not worry about
>>>> 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.
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
More information about the cairo