New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] TexturePacker: add zstd compression support #23306
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
I've made some formatting changes to meet the current code style. The diffs are available in the following links: For more information please see our current code style guidelines. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a brief glance at the code but unfortunately can't go through it. This is a really cool feature. Do you think zstd could be used in RetroPlayer some day?
@lrusak this needs a rebase |
From another project which used lzo/lz4 I mentioned to them about the guy that created lz4, created zstd. Just its a bit more modern and offers more flexibility in compression levels. They added support and I was able to do some testing, my take away is that zstd takes advantage of modern hardware better and even at its default compression levels was offering better compression (~20%) for the same or quickier performance. |
Hell yeah! I integrated lz4 three years ago, and now I have zstd available as well. I want to try both at compressing XOR'd savestate memory and see how each algo does. @lrusak I'm getting compiler errors on Android arm/arm64/x86:
https://jenkins.kodi.tv/job/android-arm64-docker/2991/console |
Getting a libcurl linking error, linking libkodi (I know this PR is TexturePacker only but it seems to affect libkodi in my personal test builds):
LMK if you rebase and want further testing. |
This is something I've been playing with after doing the TexturePacker modernization.
This add zstd compression/decompression support.
I originally had this in two parts but the changes in the first part wouldn't really make sense without the second part. The first branch was here -> https://github.com/lrusak/xbmc/commits/TexturePacker-PR-4
Compression support to
TexturePacker
and decompression to Kodi viaCTextureBundleXBT
.I've added a switch to TexturePacker (
-compression-method
) to allow selecting the compression method method. If we want to allow the use of zstd compression we may look at deprecating lzo (though it's harmless to keep both) other than dependencies.This also bumps the
XBTF_VERSION
because of the newm_compressionMethod
member that is added to the serialization in the xbt file.I've also added the cmake option
-DTEXTUREPACKER_COMPRESSION_METHOD=[zstd|lzo|none]
that can be used to select the compression method used to create theTexture.xbt
bundle at build time.I plan to add some more metrics that measure the speeds in the future but this is what I have for now. This is all on my i7 so it would be interesting to see on a low power arm device
TexturePacker:
vs
Decompressions time is similar (zstd | lzo):
File size is similar:
vs
This is just with the default zstd compression level (3).
What is the effect on users?
Faster Textures.xbt bundle decompression? Smaller Textures.xbt bundle size?