[GRASS-dev] Cairo monitor driver

[Glynn Clements]

Lars Ahlzen wrote:

> >>> Since the Cairo graphics library (http://www.cairographics.org, LGPL
> >>> licensed) provides very high-quality graphics output in several vector
> >>> and raster formats, I thought it would make sense to create a "pseudo"
> >>> monitor driver for it (similar to the PNG and PS drivers). So I did.
> >>> Cairo does all of the hard work, so it's really mostly simple "glue" code.
> >> Indeed. I have been using it for all of my R work lately. I don't know why 
> >> this hasn't come up before, but something like Cairo actually solves a lot of 
> >> the problems we are facing: high quality on-screen display, output to PDF...
> >>
> >> This would also solve the translucency problem, as Cairo can deal with that 
> >> quite nicely. 
> > 
> > The problem with translucency is that not all rendering systems
> > support it. The core X11 protocol doesn't, so you either need the
> > Render extension or to perform the rendering client-side.
> 
> I believe that Cairo does this client-side for X surfaces, so one 
> wouldn't really need to worry about it.

Doing it client side can be a major performance hit. Apart from
anything else, all of the rendering has to be done in software; your
graphics hardware can't help.

OTOH, we're already taking that hit with gis.m/wxGRASS and the PNG
driver. It's less significant for simple visualisation, but it could
be a major issue for interactive editing of vector data.

> > PostScript doesn't support it, as most printers only have one bit per component.
> 
> True. Not much do do about this case (other than perhaps use PDF, and a 
> printer driver that does the compositing in software before it's sent to 
> the printer).

Pre-rasterising is less than ideal, for two main reasons:

1. For networked setups, the amount of data involved starts to become
a major issue in terms of network bandwidth and disk usage,
particularly with 1200x1200 DPI printers being relatively common
nowadays.

2. The results are often less than ideal. Emulating intensity levels
through halftones has a cost in terms of spatial resolution. You get
better results if the halftoning is done on vector primitives (rather
than pre-rendered images), and if it's tailored to the actual printing
technology (for a laser printer, the transfer from the digital
framebuffer to an actual page is quite noisy, which is why the default
halftone resolution is usually substantially lower than the pixel
resolution).

You're a lot better off if you don't assume that you have a magic
bullet which will make anti-aliasing and alpha-blending work for
hardcopy as it does on video. IOW, explicitly allowing for hardcopy
devices rather than designing for video then trying to bang the
hardcopy peg into the video hole.

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