hittekaart - A GPX track heatmap renderer.

Age	Commit message (Collapse)	Author
2023-01-17	parallelize reading of GPX files	Daniel Schadt
	This is another pretty CPU bound task (parsing the XML files), so it makes sense to parallelize. We already have rayon, we already have the setting to control parallelism, so let's use it and make hittekaart fast!
2023-01-17	replace std::mpsc with crossbeam_channel	Daniel Schadt

2023-01-16	import modules from crate instead of re-defining	Daniel Schadt
	This is a bit more DRY, as we only have one place where we need to list all submodules. It does not give us the "unused function" warning anymore, but we can maybe find a different solution for that?
2023-01-16	use a single thread to write out files	Daniel Schadt
	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.
2023-01-15	add README and LICENSE	Daniel Schadt

2023-01-14	add support for reading brotli and gzip files	Daniel Schadt

2023-01-14	add a cli option for the output directory	Daniel Schadt

2023-01-14	make number of threads configurable per CLI	Daniel Schadt

2023-01-14	start on a proper CLI	Daniel Schadt
	This involves actual command line arguments, and more progress bars!
2023-01-12	parallelize PNG encoding	Daniel Schadt
	This gives a massive speedup
2023-01-12	clean up some unused code	Daniel Schadt
	Some of it was written because it fit the API, but we didn't end up using it in main.rs.
2023-01-12	make progress bars a bit nicer	Daniel Schadt

2023-01-11	add some first benchmarks	Daniel Schadt

2023-01-11	rename project to hittekaart	Daniel Schadt

2023-01-10	considerably speed up the rendering process	Daniel Schadt
	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.
2023-01-08	add a progress bar	Daniel Schadt

2023-01-08	fix janky lines	Daniel Schadt
	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.
2023-01-08	Initial commit	Daniel Schadt