[cairo] cairo internal design ideas

[David Reveman]

On Wed, 2004-09-22 at 19:07 -0400, Carl Worth wrote: 
> On Tue, 21 Sep 2004 12:56:21 +0200, David Reveman wrote:
> > I've got some ideas for how we could change the internal design of cairo
> > to make it more efficient, more flexible and solve some the problems
> > that currently exist. Comments and suggestions are as always much
> > appreciated.
> 
> David,
> 
> Thanks so much for looking into this. This kind of rework is exactly
> what we had in mind when we decided to make the backend interface an
> implmentation detail rather than a public export. I'm glad to see work
> like this going on.
> 
> I've got only a few general comments at this point.
> 
> > 1. The surface backend interface is not very flexible and doesn't fit
> > many of the output devices that we like to support. Hence, supporting
> > higher level output devices like PS, PDF and SVG in a good way, is not
> > possible through the current backend system and would require backends
> > to be able plug in at a different level and that would make things more
> > complicated.
> 
> That's true to some extent. But the new proposal also may not be
> adequate for some things I would like to see in a high-level
> backend. For example, I think it would be great to have a "save as SVG"
> as a common operation on any window. And then I'd like to get SVG out
> that is editabled, (ie. with paths as paths).
> 
> This is a very different scenario than generating PDF or PS for printing
> which involves a tessellator/rasterizer that we don't control. In that
> case, there are situations where we will want to push to a low level to
> guarantee high quality even with buggy rasterizers.
> 
> So, it may end up that we actually will want two different ways to get
> output out to things like PDF/PS/SVG.

I don't know if you've read through my suggestions but the stuff you're
explaining here is exactly what my solution would handle. With my
solution we wouldn't just have two different ways to get output out to
PDF, PS and SVG, we would have as many as we like. It would be up to the
specific backend to decide.

> 
> > 3. Clipping is inflexible and the way it's done right now is not
> > efficient for all backends.
> 
> This is clearly a problem, but I think it should be pretty easy to fix
> without a major re-working of the whole interface. For example, just
> switching to a trapezoid-based interface rather than surface-based would
> help a lot, right?

hmm, not much. SVG and PDF backends wouldn't like it very much.

When it comes glitz and what we can do with graphics hardware, this is
what I think:

No hardware I've seen can do much more than clipping to a simple
rectangle. Hardware rasterization of polygons can of course be used for
clipping but that only works when we don't use polygon rasterization for
the primitives we're rendering. This means that, if we both have a set
of path trapezoids and a set of clip trapezoids, one of them needs to be
converted into a pixel mask and that's not very efficient.

A better solution would be to do the clipping in software and just send
one set of trapezoid primitives to hardware. So how do we do this? Well,
to me, the tessellator is basically doing clipping. If we could get the
tessellator to do all clipping (we send it a drawing path and a clipping
path and it returns one set of trapezoids) that would be perfect. Do you
think this is possible?

> 
> I can't yet comment much on your specific proposals[*], but my general
> advice would be to approach this one step at a time, and focus on things
> that solve problems we've already run into more than things for problems
> we may hit later.

thanks Carl :)
but I think that most of the problems I'm approaching are actually
problems that we've already run into.
 
Lately, I've been trying to get the internal pattern system working
better without doing a major change to the surface backend interface,
but I've found it impossible to come up with a good solution for this.
Aware of the other problems with the current interface, I've found a
major re-design of the surface backend interface the only really good
solution and when considering such a change I think it's actually quite
important to discuss problems that we may hit later.
 
-David