Supporting Variable Size Images

[TimOliver]

G'day @mallorypaine (and @LucasTizma)! 😁

Thanks so much for ensuring this project continues, even after Path's complete discontinuation. 🙏

I've been incredibly interested in this library for a comic reader app I'm building as a fast way to show thumbnails of both comic covers, and the individual pages.

That being said, given how ridiculously variable the sizes of the comic pages could be, I definitely think there would be a lot of value in adding support for variable sized images in one catalog file.

I saw the issue discussing this feature in the original repo and it sounded like everyone agreed it was a great idea, and was actually viable.

While I still haven't finished going through how this library works in its entirety, I'm interested in trying to implement support for variable image sizes myself.

Before I start doing any work though, I thought I'd confirm in here that this is still a feature you think the library needs. And if that is the case, what was your original vision for how this should work? There was talk of needing a 'sidecar' file to store the indices and offsets of each image in the image catalog. Had you given any more thought to that?

Thanks a lot guys! I hope you had a fantastic 2018! :)

[TimOliver]

Actually. I've been thinking about this for the past few days.

This might be completely impractical, but I wonder if it's possible to blend the concept of this library with Realm in order to support variable sized images.

Realm also uses mmap to back data straight to disk, and it being a database, already has the implementations for storing raw data at arbitrary lengths, as well as defragging operations to clean up gaps caused by the data changing over time.

I might see if I can make a prototype of that first now. :)

[mallorypaine]

I’m not sure you’d achieve similar results via realm. There are a lot of specific details in the implementation of FIC that make it so fast...mapped data is just one part of the sauce. Constant-time lookup and the way segments are mapped are some of the other ingredients.

[TimOliver]

Hey @mallorypaine! Yeah, I was figuring as much. Depending on how Realm arranges its data on disk, it's easily possible it's not stored in a way Core Animation can load without having to do a copy.

If you do have a free moment at some point, I'd love to hear how you'd envision variable size images in FastImageCache being implemented. Assuming it's changed since that 2013 thread. :)