[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".
Path.
-Paul
--
Is there no safe way to travel? Nottingham, GB
More information about the cairo
mailing list