Application: gvSIG desktop

To have a base for how changes might affect performance, current numbers in my machine are, using the same layer:

- gvSIG 1.11: 3-4 seconds.
- gvSIG 2.0 (current development trunk after build 2049): 17-18 seconds.

From now on I will use the following project to test performance related changes:
https://devel.gvsig.org/svn/gvsig-plugintemplates/org.gvsig.example/trunk/org.gvsig.example/org.gvsig.example.viewer

This is a map viewer which gets the store parameters as command line parameters. I have added an option to the BaseTaskStatus that, in debug, shows how much time has taken the status, like the one created by the AbstractVectorialLegend draw method.

It seems we lost an optimization in the geometry draw process: when a geometry is going to be drawn as an AWT Shape, its coordinates are converted to integer and the geometry is simplified if its points are repeated.

This is the case of the highways layer, when the full layer is drawn there are geometries with a lot of points (100) which become much simpler geometries (10 points).

With the r38884 changeset it is readed. Now the drawing takes 15-16 seconds (12% - 17% improvement)

With the changesets r38889 and r38890 now it takes 14 - 15 seconds (7% improvement)

The changes in the r38891 leave it in 11-12 seconds (20% - 22% improvement!!)

Now the part taking most time is the creation of the geometries in the shp provider (50%). I think it could be greatly improved if the providers could directly create the simplified geometries for the view, when a scale is provided.

One posible way to do it could be to use a simplification algorithm, like the Douglas-Peucker one (see also an example usage in Openlayers), with the tolerance factor based on the scale.

Another part that could be improved is the iteration through the features. It takes almost 20% of the time, and from the data only the geometry envelop is read, as for drawing without labeling and the default legend no dbf data is loaded.

One way could be to avoid calling all the resource locking code for each iteration, doing it only once, at least when using a visitor to iterate through the features.

It would be interesting to compare also the performance when data from the dbf is loaded, by using a legend or labeling which needs alphanumeric data of the Feature.

gvsig-desktop:r38925

Fixed size of arrays (set to maximum needed from the start, they are "final")