Skip to content
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

Feature Request: decompress from input Iterator to output Iterator (for low RAM usage in embedded Rust) #140

Open
neil-morrison44 opened this issue Jul 20, 2023 · 2 comments

Comments

@neil-morrison44
Copy link

Hi,

Feel free to point me in the right direction if this is supported just now (or is implemented in another crate I've not found yet), but what I'm looking for is a function with an input similar to decompress_slice_iter_to_slice but that returns an iterator I can iterate over to get decompressed data. I'm trying to run on RAM constrained devices in no_std, eventually reading image files and writing pixels directly to the display.

Ideally, and I might be far off here from how it'd actually need to work:

  • the decompress_* function gets called & is given an Iterator that returns u8s
  • it returns a struct implementing core::iter::Iterator over u8s
  • calling next() on the returned iter will fill a (small) internal buffer by calling the input Iterator, decompressing, then transparently returning values from the output buffer until it's consumed, refilling it as needed

Ideally the size of the internal buffer would be definable by the user (const generic?, heapless does something similar) within whatever bounds make sense.

This is potentially related to #25 but more targeted towards resource-constrained devices (embedded Rust etc)

@oyvindln
Copy link
Collaborator

Yeah it seems reasonable to have something like this for cases where flate2 is too heavy. I've not personally done much work on this library in quite a while, might look into it at some point if no one else starts tinkering with it but might take a while.

@neil-morrison44
Copy link
Author

I'm still thinking about this one occasionally - I think it'd be fairly easy/nice to do with a generator which'll be available in the 2024 edition. Since iterator in / iterator out things should become really neat with generators.

I'll probably have free some time at the end of the year to look into it, unless anyone else wants to.
(Which'll align with the 2024 edition's planned release in early 2025)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants