[cairo] span datastructure

Jeff Muizelaar jeff at infidigm.net
Mon Nov 17 07:14:15 PST 2008

On Mon, Nov 17, 2008 at 12:43:13AM +0200, M Joonas Pihlaja wrote:
> On Fri, 14 Nov 2008, Jeff Muizelaar wrote:
> >blit_with_span_renderer():
> >
> >I was wondering why you create the span array instead of just blitting
> >directly from the cells.
> The spans array is a compromise between having a fast 
> implementation and a retargetable API.  Blitting directly from 
> the cell list would be letting the particular implementation leak 
> out of the scan converter.  While it's not apparent anymore given 
> that there's only one scan converter and span renderer 
> implementations left, it's been pretty useful to separate the two 
> using a simple interface.
> An even simpler interface would be a single "render this span" 
> call back, but since there are usually lots of short spans from 
> antialiasing, the span renderer call overhead starts rearing its 
> head.  A span array per pixel row seemed like the next simplest 
> thing to do.
> >It seems like doing the extra step of converting to a span 
> >array including counting the number of entries in the list 
> >isn't going to be particularily helpful for performance.
> That's true, but I haven't really seen it in the profiles so much 
> compared to advancing edges or the compositing done later, 
> especially if we're supersampling on that pixel row.

If it doesn't show up in the profiles don't worry about it for now. What
have you been profiling against? It would be interesting too see the

> Regarding counting the entries on the list it's only needed to 
> make sure we don't overflow the span array when forming it.  It 
> looks a bit shoddy and I'll admit I didn't think very hard when 
> writing that bit.  I guess we could use the width of the clip 
> region to allocate a span array we'll know to always be large 
> enough up front.

If it doesn't show up in the profiles don't worry about it.


More information about the cairo mailing list