[GRASS-dev] display/drivers/HTMLMAP status
Moritz Lennert
mlennert at club.worldonline.be
Tue Feb 20 13:24:59 EST 2007
On 20/02/07 01:41, Glynn Clements wrote:
> Moritz Lennert 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.
>> 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. No time for more
now, but I have attached the script I used if anyone else wants to try
(you have to redirect stderr to stdout to catch the output of the 'time'
command: sh render_test.sh >> render_test.csv 2>&1). I modified the
region settings by manual zooming.
Tomorrow I can try some other region settings and drivers. Glynn, any
preferences ?
Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_test.csv
Type: text/csv
Size: 2252 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070220/6544c67a/render_test.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_test.sh
Type: application/x-shellscript
Size: 414 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070220/6544c67a/render_test-0001.bin
More information about the grass-dev
mailing list