[cairo] cairo internal design ideas

Paul Sladen xr at paul.sladen.org
Wed Sep 22 19:07:11 PDT 2004

On Wed, 22 Sep 2004, Jost Boekemeier wrote:
> > Hence, supporting higher level output devices like PS, PDF and SVG in a
> > good way 
> Can you please explain this?  At least for PDF and SVG it is not a
> problem to render trapezoids.

I would be inclined to put forth a differing viewpoint;  that rendering
trapezoids is perhaps less efficient that you'd imagined.

The reason why it makes sense to tessellate (in some cases), is that current
framebuffers have been optimised for:

  * Drawing filled, alpha-blended, interpolated patterned triangles

The previous wave of acceleration was to optimise hardware paths for:

  * Drawing device-affine solid lines and rectangles.

Browsing the Mesa source, it is possible to see how the Mesa plain-X11
backend uses the these functions where it can.  With non-antialiased,
flat-shaded codepaths it performs scanline rendering using the hardware
hline functions to draw between the left and right edges.

Note the "scanline" bit, not tessellated triangles.

> If you are concerned about the document size, just compress the streams.  

A point to consider here is perhaps;  PDF is not a final-format.  It is
possible to edit PDF files just as you would SVG.  Whilst document size
comes into it, it should ideally be secondary to preserving as much meta-
data as possible.

For rendering the prettiest possible PDF files, I want any scanline- or
tessellation-processing done at the very last possible minute---and in the
device-dependent-units it is going to be drawn into.  This way, I can ensure
no line is more than (say) 1px in error;  regardless of how small a pixel 
is, or how much I've zoomed in.

I believe somebody else posted `basket.pdf'---the top is not an arc, it's
not even beziers pretending to be an arc.  When it comes to efficiency, the
ideal output would be:

  2 w                   % stroke width
  0.3 0 0 RG            % fill colour
  0 g                   % stroke colour
  0 0 m                 % moveto bottom left
  100 0 l               % bottom right
  70 20  30 20  0 0 c   % arc, right, left, back to start.
  b                     % closepath, then fill, then stroke

(These can be derived roughly 1:1 from the commands Cairo received).

In the case of the tessellated output.  There are 12 different PDF-level
objects (vs. a single stream...);  The file contains 502 moveto's and 1506
lineto's (1 moveto + 3 lineto for each quad).  In addition, the lines are
not being stroked, but drawn as more polygons.  Constrast that 52kB with the
292 bytes above (including comments and blank space).

I can send you an SVG of the result mess if you'd like, so that you can try
`adjusting' it Inkscape :-)

> Well, it depends on what exactly you mean with "high level objects".


Is there no safe way to travel?  Nottingham, GB

More information about the cairo mailing list