[cairo] GSoC: Scan converting rasteriser update

[Vladimir Vukicevic]

On Oct 6, 2008, at 8:40 AM, Behdad Esfahbod wrote:

> Carl Worth wrote:
>> On Wed, 2008-10-01 at 15:19 -0400, Jeff Muizelaar wrote:
>>> Overall comments:
>>> - I don't really like the make_span_renderer interface. It might  
>>> be better if
>>>  instead of relying on the fallback surface, we had helpers that  
>>> would be called from
>>>  the image surface's fill and stroke methods.
>>
>> Agreed.
>>
>> This approach is a general one that could be applied liberally to
>> cairo's code base to clean it up considerably. That is, it would be  
>> nice
>> to have explicit code in each backend for each interface, calling  
>> into
>> specific helper functions, rather than just returning UNSUPPORTED and
>> relying on the fallback code to do something, (which might not be
>> optimal across all backends). And even if the fallback code doesn't
>> perform poorly, it makes the code much harder to read.
>
> Actually I don't agree.  Having to make a call instead of just  
> returning
> UNSUPPORTED is going to make the code for backends considerably  
> uglier.  Right
> now one does ot even need to implement many of the methods.  Without
> UNSUPPORTED one has to copy paste a lot of cruft, that need to be  
> changed in
> 10 places everytime the fallback implementation details change.
>
> 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.

I agree with Carl here -- having the fallback invoked explicitly in  
the backend would lead to much simpler and clearer backend code.  The  
way that it's structured currently, there's magic that happens in  
multiple places, and you have to follow the UNSUPPORTED-returns back  
to wherever they were handled.  It's pretty confusing and hard to  
read, and also doesn't allow for some optimizations based on having  
more finer-grained control of when/how to invoke fallback code.

There isn't a lot of cruft that has to be copy-pasted, and I think  
that if the fallback API signature does change, then backends should  
verify that that's still correct (though why would the fallback  
signatures be anything but the same as the backend API, in the most  
general case?  anything more specific would be, well, specific).   
This, along with keeping paths as doubles until they need to be fed  
into cairo's tessellator, are two things that I've wanted to do for a  
long time...

     - Vlad