[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