4 ms·
The two approaches seem to serve different use cases. Mapping to a sprite-sheet (how FastImageCache describes itself) doesnt matter if images arent actually reu
by JamesSwift 1y ago
The two approaches seem to serve different use cases. Mapping to a sprite-sheet (how FastImageCache describes itself) doesnt matter if images arent actually reused often (eg doom scrolling). But if you do tend to either reuse the same image or scroll up/down on the same content then yes it will come out ahead.
Ive seen a lot of async image loaders over the years on ios and for the most part they were all fine. The async offload and pushing remote url loading to the background is the most important part of what was historically missing from the first party ios api.
- conradev 1y agoI largely agree. The other thing that happened is that phones got faster: it just doesn't matter as much anymore. A slow disk cache is fine, but if it does anything on the main thread: straight to jail. The article is about memory efficiency, though! In order to get equivalent memory behavior the buffers would need to be marked as purgeable (from the article) so that kernel can empty the cache if needed. Not sure if any of these libraries do that. The main situation where cache speed is tested is app launch: load every image for the current viewport simultaneously. It can take some time if your images are slow to decode.