Rendering maps better schedules screen updates. Rendering threads get reasonable time to produce first screens (0.5 sec, could be extended to 1 sec depending on the internal heartbeat) and until that time passes, the screen does not change. If rendering completes earlier, the screen is updated immediately (previously, there was a delay of up to 0.5 sec, 0.3 sec on average). This makes rendering of small amounts of data complete faster, and helps rendering of large amounts of data proceed with much less blinking.
Rendering a map with layers that are all slow and cannot produce any data for a long time keeps last used screen for up to 2 sec (after that, the map window gives up and paints the new screen even if it is blank).
Re-rendering a map after changes to layers (turning layers on and off, selecting objects, etc) coordinates with rendering threads to minimize blinking.
Resizing a map window coordinates with rendering threads to minimize blinking.
(Fix) Zooming a map by scrolling the mouse wheel no longer sometimes exits zooming prematurely (and restarts it from the new zoom level).
Rendering a map with an overlay after zooming it by scrolling the mouse wheel no longer sometimes shows the overlay twice - once as part of the scaled screen and also as a true vector overlay.
Rendering web images from image server data sources first paints data at reduced resolution and then gradually details it. This quickly fills the screen with rough data at the cost of about 10% more fetched data (frequently served from cache). The optimization works for images in parent data sources that reference table in the image server data source. If the window is small, the optimization is turned off.
Rendering a map with a lot of layers limits the number of rendering threads to make better use of system resources. The number of rendering threads depends on whether the window is active or not - rendering an active window can use as many threads as there are CPUs (plus a couple more to maximize utilization as threads switch between layers), rendering an inactive window can use up to two threads. If an active window becomes inactive, its existing rendering threads are allowed to complete and the limit is only applied towards new threads. If an inactive window becomes active, new threads are created immediately.
Logging rendering time for a map no longer logs the average number of threads used during the rendering session (with dynamic adjustments to thread limits it is hard to make this value useful). If the rendering session was interrupted with some of the layers being re-rendered due to changes in their data, rendering time is not logged (this was creating inaccurate reports before).
(Future areas for improvement in rendering: (a) preview blinking - previews already blink much less than before, but we can do more, we have several other changes planned for previews, reducing blinking will come as part of those changes, and (b) maps with lots of layers - limiting the number of rendering threads in flight does wonders for performance, but we can do more by reducing storage requirements, particularly when layers change mid-way through rendering, this will also come later.)
New query functions: TileInterpolateKrigingRegression, TileInterpolateKrigingRegressionPar - do regresssion kriging. The parameters are those used for regular kriging plus one extra parameter for regression model (auto / linear / quadratic, specified as a numeric value). There is a new transform that uses the functions: Kriging with Regression.
(Fix) Composing intermediate levels for images correctly averages data for images with the alpha channel regardless of whether channel values have to be inverted or scaled during rendering.
ArcGIS REST dataport supports servers with exportImage command (this allows using some servers that could not be used before).
Reading TIFF files better detects images with 4 channels where the 4th channel is not alpha.
Reading DBF better detects fields with floating-point values (DBF fields are 'numeric' with no separation into integer vs floating-point, whether a field is integer or floating-point is determined at runtime).
(Fix) Writing geometry to GDB normalizes areas.
SHP reads multi-patch geometry values. Opening a SHP file with multi-patch geometry values disables writes to the geometry field (there is no good way to roundtrip these values due to current limitations of our geoms, read-edit-write would be losing data).
(Fix) Exporting a drawing to GPKG no longer sometimes fails with 'cannot change table schema'.
(Fix) Reading GPKG no longer sometimes fails to use a spatial index with a complex name due to improper quoting.
(Fix) Writing geometry values to GDB no longer loses Z data.
(Fix) Exporting a very big image to TIFF no longer sometimes fails when producing data for intermediate levels.
(Fix) Pasting a folder into another folder in a different instance of Manifold no longer sometimes creates two folders (one in the target folder, another at the root of the target data source).
End of list.