The index value needs only be big enough to handle all defined terrain types. This is a low number so we can save memory by defining it as a byte. This particularly saves memory for the CustomTerrain field in the Map class, which defines a cell layer for the map using tile indexes, so we can reduce the size of that layer 4x as a result.
This may fix issue #5916.
In any case, it's wanted because this kind of sort is "unstable".
According to the docs:
"This implementation performs an unstable sort; that is, if two
elements are equal, their order might not be preserved."
The lookup accounts for ~50-60% of the time spent in GetTerrainIndex and GetTerrainInfo, and these methods themselves can account for up to 1.3% of total CPU used so this is a small but measurable win.
- Change Map.LoadMapTiles and Map.LoadResourceTiles to read the whole stream into memory before processing individual bytes. This removes the cost of significant overhead from repeated calls to ReadUInt8/16.
- Remove significant UI jank caused by the map chooser by not including the placeholder widget. The maps render fast enough that it is no longer worthwhile and it was causing a lot of flushes which were the source of the jank.
- Trigger async generation for all maps when the chooser is loaded. This means in practice all previews will be ready by the time the user begins to scroll the selection. Since generation is fast, there is no issue with scrolling straight to the bottom and having to wait for the backlog to clear.
Method is now called ToDictionary.
- Cached a few invocations into locals which should prevent some redundant evaluation.
- Added ToDictionary overloads that take projection functions for the keys and elements, since several callsites were doing a subsequent Linq.ToDictionary call to get this.
