[GRASS-dev] display/drivers/HTMLMAP status

[Glynn Clements]

Michael Barton wrote:

> > I've added a render= option to d.vect; valid values are:
> > 
> > g G_plot_polygon (default)
> > r R_polygon_abs
> > d D_polygon
> > c D_polygon_clip
> > 
> > The descriptions simply says "Rendering method for filled polygons",
> > with no explanation. I considered adding "(developer use only)", but
> > figured that will only encourage people to try it.
> > 
> > g or c will clip to the current frame, while r and d won't. r, d, and
> > c should all work with the HTMLMAP driver (which is now working).
> > 
> > My earlier patch essentially hard-codes the r behaviour, so that's
> > redundant now.
> > 
> > The relative speed of various options in actual use would be
> > interesting, although the actual results will vary substantially
> > depending upon the data, the "screen" (window/image) size, the driver,
> > etc.
> 
> Is one of these methods a better (or worse) default to use with direct
> rendering via the GUI?

Probably. I have no idea which one, though.

In general, it will depend upon the resolution of the vector data
(number of vertices), the resolution of the screen (i.e. image), and
the proportion of the map which is on screen.

Relevant facts include the following:

If you have detailed vector data which extends significantly beyond
the region, r/d (which are effectively identical) take a performance
hit from sending the vertices to the driver, which will effectively
discard anything which lies off-screen. This is less of an issue with
direct rendering, as the vertices don't have to be sent over a socket.

If the current frame doesn't cover the entire screen, r/d don't clip
to the frame. This isn't an issue with gis.m, where the current frame
is always the full screen (d.frame doesn't work there due to the lack
of persistence when using direct rendering).

The clipping performed by the g and c methods provide a performance
gain if the data extends beyond the current frame. However, it also
has a cost. For g, the cost depends upon the number of spans rendered
(i.e. will increase with a higher screen resolution, but isn't
particularly affected by the number of vertices), while for c the cost
depends upon the number of vertices (but is unaffected by the screen
resolution). The combination of these factors determines whether the
cost outweighs the benefit.

Timings for real-world usage would be appreciated, particularly for
series of results where one factor varies while the others are held
constant. Varying the displayed region and the screen resolution are
relatively straightforward; varying the number of vertices is likely
to be harder.

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