[cairo] GSoC: Scan converting rasteriser update
spitzak at thefoundry.co.uk
Mon Oct 6 11:51:49 PDT 2008
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
More information about the cairo