Glynn Clements wrote:
One relatively recent change that may cause a slow-down is that the
display library no longer tries to automatically simplify vectors
(reduce consecutive short line segments with a single segment). This
could have a significant impact when viewing detailed vectors at low
zoom.
OK. It does have a significant impact when viewing detailed vectors at
low zoom (relatively detailed: 25MB coor, 31MB topo, not that large but
complicated topology). I can't see a speed difference with small
vectors. That just got me by surprise because I was used to a 7.0
display that's faster, better, nicer than the 6.x display. Usually, the
screen resolution can't represent that detail (same for raster map
display), but I guess it is more correct to try to display all detail.
Part of the problem is that a driver can generate either raster output
(PPM, PNG, etc) or vector output (PDF, PS, SVG), and the higher levels
don't know which is the case. For vector output, there is no obvious
threshold below which additional detail becomes unnecessary.
The display library has a function, D_set_reduction(), which will
merge adjacent line segments which are below the specified size, but
nothing uses it yet.
This high amount of detail is completely lost on me, because when I
fully display a high-detail vector (zoom to map), the screen pixel width
of the boundaries is often larger than the screen pixel dimensions of
the area these boundaries belong to. With default settings, lines black
and areas grey, all I see is black in those parts of the vector with
many small areas, no detail recognisable. I use standard monitors each
with 1280 x 1024 resolution (dual screen setup) and gui display
maximized on one screen.
IOW, I could do without sub-screen-pixel detail :-)
But I don't have a solution.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
