[GRASS-dev] display/drivers/HTMLMAP status

[Glynn Clements]

Hamish wrote:

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

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

> 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'.

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