[cairo] GSoC: Scan converting rasteriser update

[Jeff Muizelaar]

On Mon, Nov 10, 2008 at 05:28:52PM +0200, M Joonas Pihlaja wrote:
> 
> On Sat, 8 Nov 2008, Jeff Muizelaar wrote:
> 
> >[cairo-spans] New _cairo_path_fixed_fill_to_span_renderer().
> >- OUT_self doesn't really follow a the cairo style
> >- OUT_converter in _begin_rendering()
> 
> OK.
> 
> >- I wonder if _cairo_path_fixed_fill_to_span_renderer() would be simpler if
> > _begin_rendering and _end_rendering were not split out. I think it could
> > simplify the error handling.
> 
> They're left over from the ..._stroke_to_span_renderer() I took 
> out.
> 
> >[cairo-spans] New cairo_delta_spans_t.
> >- I need to look at this more
> 
> That's on its way out.  I'm thinking I should take the tor scan 
> converter and shake out a mono one from it, and at that point the 
> current mono scan converter and delta spans can go away.
> 
> >[cairo-spans] Render clip mask surfaces with spans if we can.
> >- _cairo_clip_intersect_mask_with_spans() isn't a good name
> > it makes it sound like we are intersecting the mask the some spans
> > when in fact we are doing an intersect between two masks()
> > using a span renderer
> 
> I chose that as an alternate implementation of 
> _cairo_clip_intersect_mask().  Any suggestions for a good name?

_cairo_clip_intersect_mask_using_spans() is better but still not great.

> >- can we use SRC to an unitialized surface instead of initializing a 
> >surface
> > and then doing ADD?
> 
> Uninitialised surfaces wouldn't work since SOURCE is defined to 
> be bounded by the mask.  Can we add an unbounded SOURCE at some 
> point to cairo?

Cairo's SOURCE is bounded by the mask; however, pixman SOURCE is not.
If you change it to SOURCE it should just work, but it isn't necessarily
the right thing to do because we're sort of lying about the semantics of
SOURCE. I'm not really sure what the right thing to do here is. It also
makes me wonder: does the span code bound the SOURCE operator? I had a
quick look and it looks like it doesn't.

> 
> >- we should also probably not construct a new surface unless the new clip
> > is much smaller than the current clip otherwise it feels like we are 
> > wasting
> > our time constructing a new clip when the old one will do.
> 
> But that's how cairo-clip.c works?  Duplicating/cloning a clip 
> needs to be fast since it's done by cairo_save()/restore(), so 
> we're doing only shallow copies then and sharing the mask 
> surfaces of the clip.  We could optimise the case when the 
> current cairo_clip_t has the only reference to the surface, but 
> I'd add that as a separate thing.

Right. Ignore my comment then.

-Jeff