Sdwebimage: Why not store the decoded webp image ?

[bembem1011]

After using sdwebimage to work with webp image and reading code in current version, I see sdbwebimage save the downloaded data instead of saving the decoded webp image to disk. Why not supporting for saving decoded webp image ? Because after reading the downloaded webp data which stored at disk, the framework will parse downloaded data to UIImage. Doing parsing large data will cost time. I think we should support for saving decoded data to disk in next version

[dreampiggy]

@bembem1011 We can't simply store the decoded webp image like you say, it contains many bad effect.

When you decide to store the decoded webp image, actually you means to ENCODE the UIImage again and store the data. Right ? However, since many of our feature may relay on the original image data(For example, scale down or our transformer feature in 5.x)

And there are also a question, show this behavior only applied for WebP images ? What about GIF, APNG, BPG and so many other image format ? (We support custom coder to enhance your feature)

So, maybe currently we could not change this behavior. If you're really considered to use this behavior, you can try using Custom Download Operation

[bembem1011]

@dreampiggy Thanks for your answer, but using "Custom Download Operation" seems doesn't match with my idea. I see SDWebImageManager has method
- (id <SDWebImageOperation>)loadImageWithURL:(nullable NSURL *)url options:(SDWebImageOptions)options progress:(nullable SDWebImageDownloaderProgressBlock)progressBlock completed:(nullable SDInternalCompletionBlock)completedBlock {

I see below code in downloaded completion block
if (downloadedImage && finished) { [self.imageCache storeImage:downloadedImage imageData:downloadedData forKey:key toDisk:cacheOnDisk completion:nil]; }

May I extend SDImageCache to store the "downloadedImage" instead of storing "downloadedData" ? Is it the right solution and does it make any bad performance for webp Image ?

[dreampiggy]

@bembem1011. Actually, I means you can just return the encoded from UIImage to data's NSData instance in SDWebImageDownloadOperation's completionBlock instead of the downloaded data from server. So then the manager will use this NSData instead.

This maybe a bad idea in some cases when you may need the original data from your server but not the one you encode again from a decoded image. Another way it to use completionBlock and dispatch on global queue to encode again and then store the NSData by your own, so you don't need to custom download operation.

Maybe there is other better way to solve this problem such as provding a delegate method or extra abstract layer to allow user to return a modified version NSData before acually store it to disk(Like Kingfisher's CacheSerializer, but without that NSData to UIImage func because we already use Custom Coder for this case). But currently in 4.x it seems we can not change too much for this. I'll mark this as a feature request to see if any better idea is provided.

[bembem1011]

@dreampiggy Thanks for you answer, I agree with you about providing

extra abstract layer to allow user to return a modified version NSData before acually store it to disk(Like Kingfisher's CacheSerializer

How about providing it in next version 5.x in April ?

[dreampiggy]

@bembem1011 See #2245. If you are facing the issue of WebP decoding speed from disk cache. You can considerate to encode the image to another format such like JPEG or PNG when storing to disk cache.

[bembem1011]

@dreampiggy Thx :D:D:D:D

[bembem1011]

@dreampiggy once more question ? why not support for using FLAnimatedImageView with webp image because some webp images are so large to decode which makes app waiting a long time to construct UIImageView.animationImages

[dreampiggy]

@bembem1011 FLAnimatedImage is currently hardcoded to play GIF only. And since it's a third-party lib, we have no control or ability to modify it.

In 5.x we'll introduce a totally replacement for FLAnimatedImage and move current FLAnimatedImageView+WebCache code to another Cocoapods. And we also allow you to choose to use the original way (UIAnimatedImage from UIKit) way to play animated image.

To learn more, see #2140

[bembem1011]

@dreampiggy Thank you :)

[dreampiggy]

@bembem1011 #2245 Merged and 4.3.3 released