[GRASS-dev] display/drivers/HTMLMAP status

[Glynn Clements]

Moritz Lennert wrote:

> >>> 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.
> >> 
> >> Here's a first run on two data files, varying x-mon size and zoom. Tell 
> >> me if you need more info, and what other tests might be helpful.
> > 
> > The main thing which I notice is that there really isn't that much
> > difference. In most of the cases, the difference is <15% (there's one
> > where render=c is 50% slower, but that's the outlier, and even that
> > isn't that big a factor, given that there's some scope for
> > optimisation in D_polygon_clip).
> > 
> > Things which would make the results more useful:
> > 
> > 1. Disable boundaries; I'm only interested in the polygon filling
> > operation, and anything else just reduces the signal-to-noise ratio.
> > 
> > 2. Use "g.region -e"; the region only matters insofar as it provides a
> > (relative) measure of the number of vertices which need to be
> > processed.
> > 
> > 3. Figures for direct rendering (GRASS_RENDER_IMMEDIATE=TRUE).
> > 
> > 4. Making the results more machine-readable; a CSV file (region size,
> > screen size, rendering method, driver) would be ideal, but second best
> > would be something which I can mechanically convert into that, e.g. if
> > each set of tests was always preceded by the driver, screen size and
> > region extent, so that I don't have to manually discern the context.
> 
> Here's another short test with different GRASS_WIDTH/HEIGHT and two 
> different regions all with GRASS_RENDER_IMMEDIATE=TRUE.

Can you provide some statistics (number of vertices, edges, polygons)
regarding the map being rendered? Also, what is the total extent of
the map?

Here is a comparison between the various methods:

Region	Screen	g	r	d	c	r/g		c/r		c/g
(km^2)	(Mpix)	(s)	(s)	(s)	(s)	(ratio)		(ratio)		(ratio)
266	0.3072	01.51	00.97	00.97	01.16	0.642384	1.19588		0.768212
266	1.2288	02.68	01.55	01.55	01.71	0.578358	1.10323		0.63806
266	4.9664	05.29	02.71	02.72	02.87	0.512287	1.05904		0.542533
266	19.8656	10.57	05.18	05.16	05.30	0.490066	1.02317		0.501419
266	79.4624	25.11	10.93	11.00	10.99	0.435285	1.00549		0.437674
64.998	0.3072	01.17	00.93	00.92	00.55	0.794872	0.591398	0.470085
64.998	1.2288	02.18	01.65	01.52	00.75	0.756881	0.454545	0.344037
64.998	4.9664	04.12	02.77	02.78	01.21	0.67233		0.436823	0.293689
64.998	19.8656	08.46	05.46	05.74	02.56	0.64539		0.468864	0.3026
64.998	79.4624	18.59	11.94	12.25	05.22	0.642281	0.437186	0.280796

In this case, c is always faster than g, probably due to the lack of
protocol overhead. Unsurprisingly, the ratio becomes more pronounced
at larger screen sizes (where the rendering overhead is greater) and
smaller regions (where geometric clipping will reduce the amount of
data being rendered to spans).

For the large region, c is roughly equal to r, in spite of r not
clipping (i.e. the cost of clipping is recovered by the reduction in
the rendering). For the small region, it's significantly faster (the
clipping overhead remains the same, but the reduction in rendering is
much greater).

OTOH, the figures for the larger screen sizes are probably not useful;
even 2560x1940 is unlikely to be common.

Even the current (relatively inefficient) clipping seems like it will
typically be a net gain (obviously, if the entire map lies within the
region, it has to be a net loss, as clipping doesn't reduce the amount
of data at all).

For stand-alone drivers, simplification (eliminating zero-height
edges) may still be necessary to reduce protocol overhead.

> Tomorrow I can try some other region settings and drivers. Glynn, any 
> preferences ?

Stand-alone driver, small screen, complex map (many vertices),
variable region (from the entire map down to a tiny subset). This is
likely to be the worst case for render=c. That will provide baseline
values to evaluate the usefulness of particular optimisations.

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