Post by Moritz Lennert Post by Glynn Clements Post by Moritz Lennert Post by Glynn Clements
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,
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).
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
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
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
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.
Post by Moritz Lennert
Tomorrow I can try some other region settings and drivers. Glynn, any
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 <***@gclements.plus.com>