FastImageCache – iOS library for quickly displaying images while scrolling
1–10 of 35 posts
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#2It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be interesting because one is bounded on I/O, another is bounded by CPU throughput.
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#3It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be interesting because one is bounded on I/O, another is bounded by CPU throughput.
One thing that is often overlooked when considering file I/O is that the kernel caches previously accessed files for fast reads. This, combined with the lazy-loading mmap() can prove for good performance with simultaneous low memory usage for something like an image cache.
This technique is used on the iOS home screen - both the icon images and the rendered icon labels are stored as uncompressed bitmaps on disk and mmap'd when needed into memory. The fast loading allows SpringBoard to aggressively recycle icon views.
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#4It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be interesting because one is bounded on I/O, another is bounded by CPU throughput.
Wondering if there is any support for PVR compressed images(2bit/4bit)?
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#5It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be interesting because one is bounded on I/O, another is bounded by CPU throughput.
One thing that is often overlooked when considering file I/O is that the kernel caches previously accessed files for fast reads. This, combined with the lazy-loading mmap() can prove for good performance with simultaneous low memory usage for something like an image cache. This technique is used on the iOS home screen - both the icon images and the rendered icon labels are stored as uncompressed bitmaps on disk and m…
Does mmapping the file mean that it'll block on file I/O if it's not already cached, though? I don't see any claims (haven't read the code) that it prevents this.
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#6It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be interesting because one is bounded on I/O, another is bounded by CPU throughput.
It actually isn't all that surprising, we've hit similar bottlenecks where JPEG decompression on the iPhone ends up choking feeds that are scrolled through quickly.
We didn't go the route of caching the uncompressed data on disk, though, we just keep the images in a maintained in-memory cache.
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#7Whats the difference between this and SDWebImage, if any?? I cant see a ton of different API differences. Looks like this probably wont support ARC, though.
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#8A better solution then dealing with 60fps scrolling : Don't scroll, Flip!
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#9It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be interesting because one is bounded on I/O, another is bounded by CPU throughput.
It actually isn't all that surprising, we've hit similar bottlenecks where JPEG decompression on the iPhone ends up choking feeds that are scrolled through quickly. We didn't go the route of caching the uncompressed data on disk, though, we just keep the images in a maintained in-memory cache.
Exactly. I would think that a layered cache scheme probably could have the best of the two worlds (a good size of cached content on disk, and fast uncompressed image hit from memory). But using mmap'ed file instead of doing own layered cache seems less hassle. Also, you are doing decompression on a background thread, which shouldn't be much a choke on 4S and later devices (probably, again). I need to have some tests to backup my claims obviously :)
Re: FastImageCache – iOS library for quickly displaying images while scrolling
#10Earlier quoted context omitted.
One thing that is often overlooked when considering file I/O is that the kernel caches previously accessed files for fast reads. This, combined with the lazy-loading mmap() can prove for good performance with simultaneous low memory usage for something like an image cache. This technique is used on the iOS home screen - both the icon images and the rendered icon labels are stored as uncompressed bitmaps on disk and m…
Does mmapping the file mean that it'll block on file I/O if it's not already cached, though? I don't see any claims (haven't read the code) that it prevents this.
Yes. If you mmap a file and then try to access it and it's not already in RAM, you'll block while the bit you're trying to access is paged in.