[GRASS-dev] raster offset with cairo driver

[Glynn Clements]

Hamish wrote:

> > So, it's still not able to obsolete the PS driver. Initially, this
> > isn't likely to be a problem; cairo's drawing model is close enough to
> > PostScript that it would be feasible to maintain both drivers in the
> > short term.
> 
> I had expected from the current Tcl/wxPy work that the PNG driver would be the
> mainstay of the GRASS 7 desktop GUI rendering. Do I detect a hint that the PS
> driver may be challenging it for that role?

Yes. The original intention was that libraster would generate
PostScript, which would be rendered with Ghostscript for raster
output.

> (with some ps2ppm magic) Or what
> about the choice of Cairo vs. the PNG driver for ppm-backed GUI display
> windows?
> It is kind of cool to think that they may be somewhat interchangable for GUI
> rendering.

The idea was to avoid having to maintain multiple drivers along with a
mechanism to dispatch R_* calls to the appropriate driver. All calls
would produce PostScript, and the only thing that would need to be
"dispatched" is the output stream.

There isn't any point maintaining both the cairo and PNG drivers. 
cairo does everything the PNG driver does, and does a better job of
it.

If cairo could generate decent PostScript, then mapping R_* functions
to cairo functions would achieve the same result but would be quicker
for generating raster output.

Unfortunately, cairo seems too ready to fall-back to rasterising
everything, and doesn't do a particularly good job of handling raster
output (it requires that the entire raster can fit into the
interpreter's VM; not a problem when running Ghostscript on a PC, but
a significant problem for printers).

The main issue is ensuring that the fall-backs can be prevented. The
raster issue can be solved by splitting rasters into strips.

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