| Age | Commit message (Collapse) | Author |
|---|
|
It seems like this does not make the encoding slower, and the main point
is that we might want to support SQLite storage for the tiles, in which
case it might be good to have only one writer. Even with the FS-based
approach, maybe it's good to have a single thread responsible for
writing everything, and not hammer the OS with 16 write requests at
once.
|
|
|
|
|
|
|
|
|
|
This involves actual command line arguments, and more progress bars!
|
|
This gives a massive speedup
|
|
Some of it was written because it fit the API, but we didn't end up
using it in main.rs.
|
|
|
|
|
|
|
|
Most of the time was spent doing hashmap lookups because all of our
operations were done pixel by pixel, and layer.get_pixel_mut always went
through the hashmap lookup. This was true for render_circle, render_line
*and* merge_heat_counter - the last of which iterated over the full
layer every time.
The biggest change now is that we try to do accesses tile-by-tile. For
the drawing functions, this means that we render the image on a small
patch locally, and then blit the image onto the base - tile by tile,
instead of pixel by pixel.
For merge_heat_counters, we do the same: We iterate over tiles first,
keeping a reference, and then iterate over the tile's pixels - that way
we get a *huge* speedup. I can now render level 19 in 9 seconds,
compared to before when it took 20s for level 17.
Another benefit now is that we save the heatmap as u8 instead of u32.
For a single track, we could even use a single bit (though that brings
other problems with it). For the complete heatmap, u8 is probably too
small (having 256 tracks is realistic), but we can change the merged one
to be u16 later. This allows us to cut down on the RAM the program needs
considerably, as we basically only use a fourth of the space now.
A bit of noise is introduced in this patch since I ran cargo fmt.
Side note: The bottleneck now seems to be the PNG compression, so that
would be the next area to improve upon. Either by toning down the
compression ratio (at the cost of higher storage needs), or by
leveraging multithreading to deal with that.
|
|
|
|
Turns out there was a small copy-and-paste error that caused the
polygons to not line up with the circles.
The other change doesn't impact line rendering, but ensures that we stay
in u64 territory as much as possible to avoid floating point
imprecisions if the integers do get too big.
|
|
|
