[cairo] cairo internal design ideas

[Paul Sladen]

On Wed, 22 Sep 2004, Carl Worth wrote:
> On Wed, 22 Sep 2004 23:21:06 +0200, =?iso-8859-1?Q?Dirk_Sch=F6nberger?= wrote:
> > Maybe I misunderstood something, but what is a tesselator needed for e.g. a
> > Postscript paint device.
> PostScript has an imaging model (all paint is opaque)

Yes, Cairo is trying (perhaps without realising it) to be somewhere between
the PDF and SVG imaging models, both of which share a common heritage.

On that basis, my suspicion is that making the PostScript driver a
sub-filter from the PDF driver would be beneficial.

95% of the time, it will be a pass-through effectively performing a `sed'
operating on the render-streams to adjust the operator names.

The other 5% is heavy analysis;  Calculating all the intersections of
fill-areas and shooting a ray down the stack within each segment to find the
resultant colour.  If there's a bitmap in there, you're going to end up
compositing the result, which should still be bounded by real paths.

This is one reason why the PDF backend should preferably be handed real
paths;  remembering also that PDF allows combined stroke and fill without
requiring the path to be sent a second time.

PDF will also want any glyph streams handed to it with just a matrix of
where to put the item.

Pre-tesselating immediately introduces device-dependence---great for your
local graphics card or pixmap backend, but not so for other output formats;  
I'm really looking forward to anything that improves the current situation,
as you suggest.

	-Paul
-- 
Is there no safe way to travel?  Nottingham, GB