[GRASS-dev] display/drivers/HTMLMAP status

Glynn Clements glynn at gclements.plus.com
Wed Feb 14 06:57:19 EST 2007


Hamish wrote:

> > 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.
> 
> > 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
> 
> this is true when zoomed out to view entire country.
>  
> > 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 <glynn at gclements.plus.com>




More information about the grass-dev mailing list