The main focus of the build was making better use of heavily multi-core systems, particularly for raster computations. We started with watersheds and related algorithms, however the improvements we made are pretty general in nature and we are going to carry them to other algorithms in the future.
As an illustration, here's what computing watersheds looked like prior to this build, using a reasonably-sized test image on a 24-core system:
- 4 threads: 10:30 sec (10 minutes and 30 seconds)
- 8 threads: 7:00 sec -- a fair improvement over 4 threads
- 16 threads: 6:55 sec -- no improvement, basically the same as 8 threads
- 24 threads: 7:50 sec -- no improvement and actually a bit of a slowdown
- no further improvements, the times never go below 7:00
There always is a saturation point after which adding threads does not help. But we did not like that this saturation point was so low and reachable on modern systems.
After our changes, computing watersheds on the same image on the same system looks like this:
- 4 threads: 6:40 sec
- 8 threads: 3:20 sec -- a fair improvement over 4 threads
- 16 threads: 2:40 sec -- a fair improvement again
- 24 threads: 2:20 sec -- a small improvement
- no further improvements
The saturation point is much further and the overall performance is significantly better. With time, we will move the saturation point even further than that, even with algorithms that are optimized as heavily as watersheds in 9, but we feel this is a good step forward.
A number of implemented improvements benefit heavily from increasing the cache size in the Options dialog. If you have a system with 16 GB or more, consider increasing the cache size from the default 4 GB to 8 GB - half of the available physical memory or slightly less is reasonable for a desktop system with a single user session.
As we said, the improvements are pretty general in nature and we are going to carry them to other algorithms beyond watersheds. We are also working on the next version of the MAP file which will have quite a number of these improvements built into it directly. We also have a bunch of improvements planned for vectors.
Exporting an image with channels that have been remapped using the Style pane to TIFF produces data with remapped channels. (So that the exported image looks the same as the original.)
(Fix) Attempting to test a connection to a MySQL database by pressing Test in the Database Login dialog actually attempts to connect to the database instead of merely validating the connection string.
(Fix) Attempting to test a connection to an Oracle database no longer logs an error into the log window if the attempt to connect fails.
The Options dialog includes a switch to control access keys: auto (default) / show / hide.
(Fix) Importing a SHP file with no associated coordinate system info no longer sets the coordinate system of the produced drawing to the default pseudo-Mercator system instead of leaving it unfilled.
New coordinate transform type: NADCON5. Built-in coordinate system data include EPSG transforms based on NADCON5. (NADCON5 is basically the next version of NADCON with updated grids and an optional adjustment for altitude.)
GRIDS.DAT has been updated to include grid files for NADCON5 transforms.
The new version of GRIDS.DAT is backwards-compatible with the old version and can be downloaded from:
http://www.manifoldsoftwarelimited.mobi/updates/working/grids.dat (379 MB)
Reprojection dialogs collapse names of grid files in conversion paths from 'xxxxx.las + xxxxx.los' to 'xxxxx.las / los' to remove redundant repetitions.
Reprojection dialogs allow selecting a conversion path when converting between systems which have equal parameters but different EPSG codes. (EPSG data contains a fair number of such conversions.)
Exporting data to various ESRI formats writes coordinate system as a PRJ file in addition to MAPMETA.
End of list.
Further builds will focus on various small to medium items in editing / layouts / possibly labels.