[cairo] line width questions

M Joonas Pihlaja jpihlaja at cc.helsinki.fi
Wed Aug 20 12:16:19 PDT 2008

On Mon, 18 Aug 2008, Bill Spitzak wrote:

> Also OpenGL, Windows GDI, GDI+, PDF, AGG, SVG, DirectX, SilverLight, and
> a whole lot of others use "zero line width" to mean a special line
> drawing algorithim.

Uhm.. sorry for butting in here, but as I stifled myself earlier
exactly because of this point and now you bring it up, I want to
mention this.  Turns out that in SVG a zero stroke width does not
turn on hair line mode:


> In fact it has been in *every single graphics api* I
> have ever seen that has an ability to set the line width, except for Cairo.

Can you really do it in SVG too?  (I haven't gone through the
entire SVG spec with an eye out for a hair line mode.)

Regardless, I also think that a hair line mode would be an
appropriate addition to Cairo and want to help make it happen.
I've looked at the stroker and think I understand now why it's
not working as expected for things like the unantialiased-shapes
test where the uneven lines really look ugly when renderered with
the image backend.  Also have a plan in place to fix it for the
image backend at least:


(Sorry for pimping mah blog, but it's relevant, honest!)

I think that the best way to approach it API-wise is to introduce
a new stroking mode rather than trying to overload any of the
existing API.  Obviously this includes not overloading zero line
width to mean something else than a non-existent line, but also
answers like "turn off antialiasing and use a line width of 1
device unit and hope it works well."  (Even if for pixel-based
backends this is pretty much what Cairo should be doing provided
the stroker is fixed for general antialiased stroking.)

The SVG case really bugs me though... what should Cairo be doing
if the backend *doesn't* provide a hair line mode?  Not stroke at
all?  Stroke normally with a default line width in device units?
Signal an error and shut down the cairo context?

> In addition the line ends are adjusted so that horizontal and vertical
> lines are aligned with pixel boundaries so that the line thickness looks
> the same no matter where it is drawn.

I'm not sure if extra adjustment of the paths is necessary beyond
using Hobby's pen polygons and making sure the rasteriser uses a
compatible pixel sampling rule.  I guess that's what you meant,
or did you have something else in mind?



More information about the cairo mailing list