[GRASS-dev] display/drivers/HTMLMAP status

[Markus Neteler]

Hi,

I have seen that we have
display/drivers/HTMLMAP
in 6.3-CVS but it miserably fails to compile.

This is the last trace:
http://grass.itc.it/pipermail/grassuser/2007-January/037891.html

I think that it is a nice driver but I cannot estimate
how painful an update would be.

Markus

[Hamish]

Post by Markus Neteler
I have seen that we have
display/drivers/HTMLMAP
in 6.3-CVS but it miserably fails to compile.
http://grass.itc.it/pipermail/grassuser/2007-January/037891.html
I think that it is a nice driver but I cannot estimate
how painful an update would be.
The HTMLMAP driver works by "trapping" polygon-fill operations. But
d.vect doesn't use polygon-fill operations; it does its own
rasterising, and just sends a series of horizontal-line-drawing
commands to the driver.
As there currently isn't any use for the HTMLMAP driver, it hasn't
been maintained. If someone ports d.area to the new vector API, I'm
willing to port the HTMLMAP driver.

FWIW, d.graph -m draws using the same fns as d.area did:
R_polygon_abs(xarray, yarray, num);
R_polyline_abs(xarray, yarray, num);

and d.graph can be piped coordinate lists from stdin.

Maybe not the fastest way, but it might work.


Hamish

[Glynn Clements]

Post by Markus Neteler
I have seen that we have
display/drivers/HTMLMAP
in 6.3-CVS but it miserably fails to compile.
http://grass.itc.it/pipermail/grassuser/2007-January/037891.html
I think that it is a nice driver but I cannot estimate
how painful an update would be.

As I said before, unless someone fixes d.vect to use the driver's
polygon-filling operations (for map areas, not just label boxes),
there isn't any point in having the HTMLMAP driver.

[Hamish]

Post by Glynn Clements

Post by Markus Neteler
I have seen that we have
display/drivers/HTMLMAP
in 6.3-CVS but it miserably fails to compile.
http://grass.itc.it/pipermail/grassuser/2007-January/037891.html
I think that it is a nice driver but I cannot estimate
how painful an update would be.

As I said before, unless someone fixes d.vect to use the driver's
polygon-filling operations (for map areas, not just label boxes),
there isn't any point in having the HTMLMAP driver.

You say "unless someone fixes d.vect". Does that imply the current
method is broken versus using the R_*() fns? Or is it just not condusive
to a working HTMLMAP driver? Will the current d.vect method be faster
than using lib fns which will take time rendering polygons which will
end up being off screen?

bug or design choice?


Hamish

[Glynn Clements]

Post by Hamish

Post by Glynn Clements

Post by Markus Neteler
I have seen that we have
display/drivers/HTMLMAP
in 6.3-CVS but it miserably fails to compile.
http://grass.itc.it/pipermail/grassuser/2007-January/037891.html
I think that it is a nice driver but I cannot estimate
how painful an update would be.

As I said before, unless someone fixes d.vect to use the driver's
polygon-filling operations (for map areas, not just label boxes),
there isn't any point in having the HTMLMAP driver.

You say "unless someone fixes d.vect". Does that imply the current
method is broken versus using the R_*() fns? Or is it just not condusive
to a working HTMLMAP driver?

It isn't conducive to any future display architecture, either.

It's relying upon the fact that a specific sequence of horizontal
lines is indistinguishable from a filled polygon with the existing
X/PNG drivers.

Post by Hamish
Will the current d.vect method be faster
than using lib fns which will take time rendering polygons which will
end up being off screen?

It depends upon the specific case. In terms of protocol overhead,
sending polygon vertices involves sending less data than sending
lots of horizontal lines, unless:

1. The polygon edges are small (typically < 1 pixel high), or

2. Most of the polygons are off-screen, and d.vect doesn't explicitly
check for this at the polygon level.

3. A substantial proportion of the data is made up of polygons which
are mostly off-screen, and it doesn't do polygon clipping.

Regarding #2 and #3, if efficiency was the issue, there are better
ways to achieve this goal.

Post by Hamish
bug or design choice?

The two aren't mutually exclusive, but I'd say bug.

Pre-rendering relies upon driver behaviour which isn't guaranteed (and
was known to be under consideration for change at the point that
d.vect was written). If the existing drivers get replaced with
something else and d.vect no longer works, that's d.vect's bug, not
the drivers'.

[Hamish]

Post by Glynn Clements
It's relying upon the fact that a specific sequence of horizontal
lines is indistinguishable from a filled polygon with the existing
X/PNG drivers.

Will the current d.vect method be faster than using lib fns which
will take time rendering polygons which will end up being off
screen?

It depends upon the specific case.

I'll throw in my typical vector case: a high resolution vector coastline
of the entire country + the 1000s of nearshore islands, all stored in
a single vector map.

Post by Glynn Clements
In terms of protocol overhead, sending polygon vertices involves
1. The polygon edges are small (typically < 1 pixel high), or

this is true when zoomed out to view entire country.

Post by Glynn Clements
2. Most of the polygons are off-screen, and d.vect doesn't explicitly
check for this at the polygon level.
3. A substantial proportion of the data is made up of polygons which
are mostly off-screen, and it doesn't do polygon clipping.

this is true when zoomed into a specific part of the coastline.

90% of the time I am working at either one of those two scales.


Hamish

[Glynn Clements]

Post by Hamish

Post by Glynn Clements
It's relying upon the fact that a specific sequence of horizontal
lines is indistinguishable from a filled polygon with the existing
X/PNG drivers.

Will the current d.vect method be faster than using lib fns which
will take time rendering polygons which will end up being off
screen?

It depends upon the specific case.

I'll throw in my typical vector case: a high resolution vector coastline
of the entire country + the 1000s of nearshore islands, all stored in
a single vector map.

Post by Glynn Clements
In terms of protocol overhead, sending polygon vertices involves
1. The polygon edges are small (typically < 1 pixel high), or

this is true when zoomed out to view entire country.

Post by Glynn Clements
2. Most of the polygons are off-screen, and d.vect doesn't explicitly
check for this at the polygon level.
3. A substantial proportion of the data is made up of polygons which
are mostly off-screen, and it doesn't do polygon clipping.

this is true when zoomed into a specific part of the coastline.
90% of the time I am working at either one of those two scales.

The point is that, if d.vect is doing this for efficiency, it's a very
lazy approach, and one which doesn't buy you anything when using
direct rendering, where there isn't any protocol overhead. Even when
using a driver, I don't know how significant the protocol overhead is
compared to the actual rendering.

For each case, a more sensible solution is:

1. Coalesce sequences of consecutive edges to a single edge.
2. Check whether the entire polygon is off-screen.
3. Clip the polygon to the screen.

In many cases, these would save far more time than the saving obtained
by moving the rendering to the client.

BTW, none of these are specific to rendering; if the vector system
can't cull or simplify vector data, that's likely to make use of
high-resolution data (or maps covering a large area) problematic in
general.

[Glynn Clements]

Post by Hamish

Post by Glynn Clements
It's relying upon the fact that a specific sequence of horizontal
lines is indistinguishable from a filled polygon with the existing
X/PNG drivers.

Will the current d.vect method be faster than using lib fns which
will take time rendering polygons which will end up being off
screen?

It depends upon the specific case.

I'll throw in my typical vector case: a high resolution vector coastline
of the entire country + the 1000s of nearshore islands, all stored in
a single vector map.

Could you apply the attached patch, and tell me how much difference it
makes in your typical cases?

[Glynn Clements]

Post by Hamish

Post by Glynn Clements

Post by Markus Neteler
I have seen that we have
display/drivers/HTMLMAP
in 6.3-CVS but it miserably fails to compile.
http://grass.itc.it/pipermail/grassuser/2007-January/037891.html
I think that it is a nice driver but I cannot estimate
how painful an update would be.

As I said before, unless someone fixes d.vect to use the driver's
polygon-filling operations (for map areas, not just label boxes),
there isn't any point in having the HTMLMAP driver.

You say "unless someone fixes d.vect". Does that imply the current
method is broken versus using the R_*() fns? Or is it just not condusive
to a working HTMLMAP driver? Will the current d.vect method be faster
than using lib fns which will take time rendering polygons which will
end up being off screen?

One thing I have since noticed is that the existing method clips to
the current graphics frame, whereas R_polygon_abs() doesn't (the core
R_* functions only clip to the screen; they don't understand frames).

It's possible that was the reason for the current mechanism.

In any case, it would be straightforward to add an option to d.vect to
choose between G_plot_polygon(), R_polygon_abs() and the new
D_polygon() and D_polygon_clip() functions for rendering filled
polygons. All of those except for G_plot_polygon would work with the
HTMLMAP driver.

So, I intend to add such an option, and to resurrect the HTMLMAP
driver.

[Hamish]

(no time to run some time trials on your patch yet)

Post by Glynn Clements
One thing I have since noticed is that the existing method clips to
the current graphics frame, whereas R_polygon_abs() doesn't (the core
R_* functions only clip to the screen; they don't understand frames).
It's possible that was the reason for the current mechanism.
In any case, it would be straightforward to add an option to d.vect to
choose between G_plot_polygon(), R_polygon_abs() and the new
D_polygon() and D_polygon_clip() functions for rendering filled
polygons. All of those except for G_plot_polygon would work with the
HTMLMAP driver.
So, I intend to add such an option, and to resurrect the HTMLMAP
driver.

Should it be a compile time #ifdef or a module flag? ie if it will be
removed later on it might be better to hide it from the user during
development. On the otherhand it gets less testing that way. shrug.


Hamish

[Glynn Clements]

Post by Hamish
(no time to run some time trials on your patch yet)

Post by Glynn Clements
One thing I have since noticed is that the existing method clips to
the current graphics frame, whereas R_polygon_abs() doesn't (the core
R_* functions only clip to the screen; they don't understand frames).
It's possible that was the reason for the current mechanism.
In any case, it would be straightforward to add an option to d.vect to
choose between G_plot_polygon(), R_polygon_abs() and the new
D_polygon() and D_polygon_clip() functions for rendering filled
polygons. All of those except for G_plot_polygon would work with the
HTMLMAP driver.
So, I intend to add such an option, and to resurrect the HTMLMAP
driver.

Should it be a compile time #ifdef or a module flag? ie if it will be
removed later on it might be better to hide it from the user during
development. On the otherhand it gets less testing that way. shrug.

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.

[Moritz Lennert]

Post by Glynn Clements
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 images show that what is drawn on the screen is different according
to the render options: g and c clip the area fill, d and r do not.


Moritz

[Glynn Clements]

Post by Moritz Lennert

Post by Glynn Clements
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.

[Moritz Lennert]

Post by Glynn Clements

Post by Moritz Lennert

Post by Glynn Clements
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).
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

[Glynn Clements]

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,
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).
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.

Post by Moritz Lennert
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.

[Moritz Lennert]

Post by Glynn Clements
Stand-alone driver,

what do you mean by this ?

Post by Glynn Clements
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.

ok

Moritz

[Glynn Clements]

Post by Moritz Lennert

Post by Glynn Clements
Stand-alone driver,

what do you mean by this ?

I mean GRASS_RENDER_IMMEDIATE unset, i.e. using XDRIVER or the PNG
driver.

With detailed geometry, immediate rendering is likely to offer a
significant improvement over using a separate driver process, as there
isn't any protocol overhead.

[Moritz Lennert]

Post by Glynn Clements

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,
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).
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?

Sorry, had forgotten about this. It is the spearfish60 landcover map:

GRASS 6.3.cvs (spearfish60):~ > v.build landcover
Building topology ...
31758 primitives registered
Building areas: 100%
10219 areas built
2369 isles built
Attaching islands: 100%
Attaching centroids: 100%
Topology was built.
Number of nodes : 23908
Number of primitives: 31758
Number of points : 0
Number of lines : 0
Number of boundaries: 21539
Number of centroids : 10219
Number of areas : 10219
Number of isles : 2369

Is this enough info ? If you need more, could you tell me what exactly,
and maybe how to get it ?

Moritz

[Moritz Lennert]

Here's another test run. Script used and result file attached.
File info (from v.build):


Number of nodes : 67425
Number of primitives: 86425
Number of points : 0
Number of lines : 0
Number of boundaries: 65961
Number of centroids : 20464
Number of areas : 20464
Number of isles : 1464


Moritz

[Glynn Clements]

Post by Moritz Lennert
Here's another test run. Script used and result file attached.

Okay. The main piece of information here is that the protocol overhead
really isn't that significant.

[Moritz Lennert]

Glynn,

Post by Glynn Clements
So, I intend to add such an option, and to resurrect the HTMLMAP
driver.

FYI, compile error on Windows:

OBJ.i686-pc-mingw32/main.o: In function
`main':c:/grasssrc/grass6/display/drivers/HTMLMAP/main.c:45: undefined
reference to `LIB_main'
collect2: ld returned 1 exit status
make: *** [/c/grasssrc/grass6/dist.i686-pc-mingw32/driver/HTMLMAP] Error 1


Moritz

[Glynn Clements]

Post by Moritz Lennert

Post by Glynn Clements
So, I intend to add such an option, and to resurrect the HTMLMAP
driver.

OBJ.i686-pc-mingw32/main.o: In function
`main':c:/grasssrc/grass6/display/drivers/HTMLMAP/main.c:45: undefined
reference to `LIB_main'
collect2: ld returned 1 exit status
make: *** [/c/grasssrc/grass6/dist.i686-pc-mingw32/driver/HTMLMAP] Error 1

The display drivers don't compile under Windows, due to the absence of
fork(), AF_UNIX sockets, etc.

Arguably, display/Makefile should conditionalise the "drivers"
subdirectory upon "ifneq ($(HAVE_SOCKET),)", which is the test used
for that part of lib/driver (essentially, everything that's used for
standalone drivers but not direct rendering).

[Michael Barton]

Glynn,

Is one of these methods a better (or worse) default to use with direct
rendering via the GUI?

Michael

Post by Hamish
(no time to run some time trials on your patch yet)

Post by Glynn Clements
One thing I have since noticed is that the existing method clips to
the current graphics frame, whereas R_polygon_abs() doesn't (the core
R_* functions only clip to the screen; they don't understand frames).
It's possible that was the reason for the current mechanism.
In any case, it would be straightforward to add an option to d.vect to
choose between G_plot_polygon(), R_polygon_abs() and the new
D_polygon() and D_polygon_clip() functions for rendering filled
polygons. All of those except for G_plot_polygon would work with the
HTMLMAP driver.
So, I intend to add such an option, and to resurrect the HTMLMAP
driver.

Should it be a compile time #ifdef or a module flag? ie if it will be
removed later on it might be better to hide it from the user during
development. On the otherhand it gets less testing that way. shrug.

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.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton

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.