[GRASS-dev] Cairo monitor driver

GRASS GIS GRASS GIS developer
1

Glynn Clements wrote:

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.

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?

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).

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.

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

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

--
Lars Ahlzen
lars@ahlzen.com

2

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@gclements.plus.com>

3

Glynn Clements wrote:

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.

X may be an exception in that respect. Then again, have you ever used a system that didn't render them as 1 pixel lines? :wink:

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.

It may be moot with respect to 6.3.

I just want to make the driver as useful as possible. Since I still don't see any downside implementing the offset (other than a few extra lines of code), but a significant benefit, I see no reason not to do so. It's by no means urgent, though.

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

True. This will be very nice indeed! Btw, do we expect more 6.x releases after 6.3, or will all work shift to 7.x?

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

4

Hi Lars,

2007/10/26, Lars Ahlzen <lars@ahlzen.com>:

True. This will be very nice indeed! Btw, do we expect more 6.x releases
after 6.3, or will all work shift to 7.x?

I think 6.4 should be released at the end. I hope in the next week
migration to OSGeo structure will be done, GRASS7 repository created,
etc. Then all major development efforts will be focused on GRASS7.

Martin

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *