[cairo] Where's the bottleneck in using glitz/cairo/librsvg?

[Keith Packard]

On Mon, 2006-06-12 at 17:58 +0200, David Turner wrote:

> I suppose that you mean that it's not possible to tessellate without 
> finding intersections, which is
> true. However, tessellation is certainly not a requirement to perform 
> high-quality anti-aliased
> rendering, there are several alternative algorithms that can be used, 
> each one having its own
> advantages and inconveniences.

Given the goal of getting to hardware accelerated rendering, I'm not
sure how we manage that without tesselation; hardware accelerators
generally like to deal with objects with a fixed number of vertices.

As most graphics hardware can now execute fragment shading programs, it
would be interesting to explore how those could be used for
full-precision anti-aliasing.

Providing an in-Cairo software rasterizer which doesn't tesselate might
make a lot of sense though; our current architecture was dictated by the
Render extension specification.

> Also, tessellation doesn't guarantee perfection, for example the current 
> Cairo software
> rasterizer uses some form of super-sampling, which doesn't deal 
> correctly with ultra-thin
> nearly-horizontal lines (a pathological case)

Right, given the requirement that infinite tesselation still generate
non-zero alpha values, alpha must be point sampled. I've explored a few
designs which would permit a more sophisticated distribution of the
points which would reduce the pathologies present in the current
implementation.
 
> Another option would be to put the tessellation code within the X 
> server, which would only be
> used if accellerated quad rendering is available on the hardware. If 
> not, a normal non-tessellating
> rasterization algorithm would be used to generate alpha horizontal 
> spans, with just as much quality
> as the current code.

I can't put the tesselator in the X server for several reasons; mostly
that X requests are atomic, and tesselation is 'expensive' leaving us
with inconsistent latency for other applications. Secondarily, the
entire polygon "must" fit in a single X request, or at least in the X
server memory all at once; I suspect many polygons drawn today are
beyond the maximum request size supported in the X protocol. Plus, the
instances of hardware incapable of accelerating primitive polygons will
shrink over the coming years; designing a system for disappearing
hardware seems inefficient to me.

> Also, I don't know how Xara LX achieves its high-quality high-throughput 
> results, but I would be
> surprised if this involved any tessellation. Hope to see that code soon.

As the Xara code is just software, to a great extent it "doesn't matter"
to us. We must focus on the accelerated case, and design code across the
library and X server which takes adavantage of these capabilities. Even
Xara can't match the performance of glitz today.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060613/5773bbcd/attachment.pgp