[GRASS-dev] Cairo monitor driver

[Glynn Clements]

Lars Ahlzen wrote:

> >> Lines 
> >> with odd widths are disproportinally common due, among other things, to 
> >> the fact that many d-modules do not offer control over the width of 
> >> lines in their output (and always draw 1-unit wide lines).
> > 
> > Actually, Cairo's default line width is 2.0 units:
> > 
> > 	http://cairographics.org/manual/cairo-cairo-t.html#cairo-set-line-width
> > 
> > All display modules will use this value until it's explicitly changed. 
> > The cairo driver should either explicitly change the line width to 1
> > at start-up, or interpret a line width of 0 as meaning 2 units rather
> > than 1.
> 
> Good point. It makes sense to set the default line width to 1 unit, at
> the very least for PNG output, to make sure it's consistent with the
> behavior of other pixel-based monitors.

Note that you cannot get consistency with XDRIVER; X intentionally
doesn't specify the rendering of thin (zero width) lines, so that a
hardware implementation can be used. IOW, zero width lines are
rendered however the graphics chip decides to render them.

> Btw, how *should* a call to Line_width with a 0 be interpreted? As
> "smallest possible line width" or "default line width" or something else?

As the default line width, due to:

> > There are only a handful of modules which actually change the line
> > width, namely d.graph, d.path and d.vect. All three modules set the
> > width using D_line_width() (which takes a double) and set it back
> > using R_line_width(0).

Anything else will mean that you will get different results depending
upon whether one of those modules has been run since the monitor was
started.

7.x will have save/restore (for all graphics state, not just line
widths).

> > d.vect and d.graph set the width to a user-specified value, while
> > d.path sets it to 2 for "bold" lines.
> 
> Interesting. So, in other words, the width of lines produced by, e.g.
> the d.grid command, depends on the default line width.

Yes. R_line_width() is a relatively recent addition, so few modules
use it. D_line_width() is even more recent.

> Anyway, assuming that the default line width is 1 unit for pixel based
> output (to be consistent), then the problem remains.

At this point, it's largely moot.

Integrating the cairo driver (e.g. modifying libraster to allow direct
rendering via the cairo driver) is probably too destabilising a change
now that 6.3 is at the release-candidate stage, so gis.m will likely
continue to use the PNG driver.

7.x will use floating-point display coordinates throughout, so there
will be no need for any offset.

-- 
Glynn Clements <glynn at gclements.plus.com>