[GRASS-user] The upper limit for displaying large vector layers

[Glynn Clements]

Moritz Lennert wrote:

> >> Maybe related:
> >>
> >> http://trac.osgeo.org/grass/ticket/384
> >> http://trac.osgeo.org/qgis/ticket/1430
> > 
> > And another one - maybe:
> > 
> > https://trac.osgeo.org/qgis/ticket/1427
> 
> See [1] for a previous debate about the issue is.
> 
> Glynn, is this in any way addressed in your reforms of the display system ?

Yes. 7.0 uses floating-point throughout, so the half-pixel shifts
caused by integer coordinates are no longer an issue.

> In trunk, displaying the same dataset used in the example in [2] (20000 
> area), I now seem to see longer display times than before:
> 
> GRASS 7.0.svn (BELGIQUE):~ > time d.vect ssbel01 fcol=none type=area
> real    0m4.815s
> user    0m4.292s
> sys     0m0.508s
> 
> 
> Times before seemed to have been around max. 3 seconds.

Timing comparisons between 6.x and 7.x are apples-to-oranges, as so
much has changed.

If built with --with-cairo, the default display driver is cairo. You
can force the use of the PNG driver (while it still exists) with
GRASS_RENDER_IMMEDIATE=PNG.

Cairo seems to be slower than the PNG driver for simple test cases
(which seems odd, as the PNG driver's polygon filler is quite
inefficient). AFAICT, cairo's primary target is X via the Render
extension. Other targets seem to be functional rather than optimal
(its PostScript output is far from optimal, so I intend to retain the
separate PS driver for the time being).

Also, the display library and d.vect no longer support the various
render= options; there is no clipping or culling of the data before
passing it to the driver. The two main reasons for those features
(overflowing the 16-bit coordinate range used by X, and the overhead
of passing large amounts of data to a separate monitor process) no
longer apply.

With an in-process driver, I wouldn't expect there to be any benefit
to a separate clipping/culling step, as cairo (etc) has to do this
itself anyhow. But it might be doing it in a sub-optimal manner (i.e.
rendering everything then clipping at the raster level).

Also, the GUI should eventually be changed to offload most of the work
to the video hardware (GRASS_CAIRO_DRAWABLE=) rather than doing
everything client-side.

Ultimately, I don't want to waste time optimising code which could
change substantially (also, I don't want to have to modify code which
has been complicated by optimisation).

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