New, point-sampling rasterization code in libpixman (was: Re: [cairo] Hang in Cairo 0.1.23)

[Carl Worth]

On Mon, 17 Jan 2005 13:14:48 -0500, Carl Worth wrote:
> I've verified that the example code does not loop when targeting the
> Xlib backend, so the new rasterizer should fix the bug. (Not to
> mention the fact that the new rasterizer is quite a bit faster, which
> was the reason I was already planning to get it into libpixman).

I've just committed Keith's "new" point-sampling rasterization code to
libpixman, (the code that's been in the X server since August). So
this bug is now fixed in CVS and will be fixed in the new libpixman
snapshot which I'm about to make.

The new rasterization code is much simpler, and thus more robust than
the old code. In fact, when committing this new code the SVG test
suite turned up a few more alpha==1/255 "leaks" that we hadn't yet
noticed or fixed in the old code.

Good riddance to lots of nasty, complex code.

Another benefit of this change is that we should now get pixel-perfect
matches between the X server and libpixman once again.

However, the new rasterizer appears to have roughly equivalent
performance to the old one. I had thought it would be faster since I
had seen a profile report showing the rasterizer far below the
tessellator when targeting the X server. However, I misinterpreted
that test because the code was doing a *lot* of hit testing,
(ie. cairo_in_fill), in addition to drawing. The hit testing exercises
the tessellator but not the rasterizer.

So, given a sample size of one complex SVG file, (centi_unfinished.svg),
and doing nothing but drawing, it looks like the rasterization is
currently about 3-4 times more expensive than the tessellation.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050121/da3cd988/attachment.pgp