Replace ColorTree with a more performant ColorMap.#197
Open
runewalsh wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
5 years ago I tried translating LodePNG to Pascal for easier use in my projects and during that found a few ways to significantly speed up certain scenarios, so maybe over the next 5 years I’ll translate them back if you like it and your specific solutions didn’t have non-obvious reasons that I might have missed. :D
This MR changes
ColorTreeto a static 512-cell hash table. I don't thinkColorTreemakes any sense; even if you intended to find the nearest colors or so, you’d need something else.My effect on this image (RGB8):
is just reducing the amount of
lodepng_(m|re)alloccalls duringlodepng_encodefrom 1952 to 587.Effect on (re-)encoding this image, however (8-bit palette):
is speeding up
lodepng_encodeby 30% (16 to 21.3 MP/s), in addition to reducing the number of allocations from 3497 to 547. IIRC using an actualzlibmakeslodepng_compute_color_statsdominate the compression itself and leads to much larger relative savings, but I’m lazy to check exactly.