[cairo] GSoC final week

[M Joonas Pihlaja]

Behdad Esfahbod wrote:

> Now is the time to let us know how it goes, what's your plan
> for the final week, how much of what you scheduled for have
> been done, etc.

I was hoping to have awesome news by now, but the clock... it
won't stop ticking.

So I'm still writing the faster scan converter.  For some rather
stupid reasons I thought I could merge a bunch of the various
rasteriser ideas (stratified sampling, lookup table based
rasterising) into a Scan Converter of Doom[1]... and... I'm still
not sure if it'll be faster than the updated code in David
Turner's shootout. :|

I'm doing the rasteriser deving against David Turner's ftgrays
framework at the moment so that I can compare like to like
easily.  I may not be able to integrate it into my cairo branch
by the hard deadline on Monday, however.  So if it comes down to
it, I'd rather be evaled on the state of my cairo branch right
now, even if it has obvious deficiencies speed wise, rather than
the partially finished iffy code I'm still spewing.  I've nothing
to push to the branch in my pipeline unless I get the scan
converter in,

Concerning the original schedule, well, obviously I'm falling
short of it as I'm well into "pad time for schedule slippage."
Although, I should get extra credit for the extra time spent
dreaming oppressive dreams of winding counters chasing me along a
scanline. :)

I didn't get to pixman span compositing nor the new span based
clip mode, so those are still open goals.  I do have a fairly
robust pipeline in place and IMHO superior rasterisers producing
more correct reference images, so the open goals are now
reasonably orthogonal to all the other code.  The majority of the
work has been about converging on to the Right Thing To Do, while
coexisting with the trapezoid rendering code and taking advantage
of the existing optimisations when possible.  I believe the
structure of the pipeline reflects that.

But now... there's this little bottleneck I need to go sort out
now, and it'll be all smiles and pass-me-another-beer soon, I
promise. :)

Cheers,

Joonas

[1] Basically the idea is to use the lookup table based trap
rendering idea from [2], combine that with winding counters that
add 'sideways' a bit plane at a time (so that pixels without
intersections should be processed ~ at even-odd fill rule speeds
give a factor of foo,) and fall back to the subsample row DDA
approach of the ftgrays_kiia<#> for the rest.  Of Doom, I say!

[2] http://lists.freedesktop.org/archives/cairo/2006-November/008433.html