Add support for Progressive JPEG.

[oferRounds]

Hi!

Thanks for this awesome library!

I wanted to ask please: does the library support progressive JPEG?

Thanks!

[DylanVann]

Thanks, glad you've found it useful. Progressive JPEG probably won't be supported anytime soon. It's not officially supported by either of the underlying native libraries. By not supported I mean I believe it will display them, but it will not display them progressively.

I guess Progressive JPEG support is one nice feature of Fresco.

[oferRounds]

Cool, thanks! I know it’s a big change, was it considered to use PinRemoteImage? It supports P-JPEG, and also – coming from iOS – I found it better to work with comparing to SDWebImage.

[oferRounds]

Just looked on Fresco - yes, it looks great with their built in support for both progressive JPEGs and WebPs.

Maybe it‘s worth checking the option to migrate to Fresco and PinRemoteImage.

[DylanVann]

There isn't much chance of migrating to Fresco since problems with Fresco are why I made this in the first place.

Last time I checked SDWebImage was one of the fastest / most performant image loading libraries, so I wouldn't want to switch off unless I'm sure PINRemoteImage can provide the same performance. It's also still in beta.

[oferRounds]

I understand, no problem. But just to mention: as far as I know – and according to their page also – PINRemoteImage is not in beta. Pinterest themselves use it in their iOS production app. I also used it in the past on my non-RN app.

[DylanVann]

Oh, I suppose it's just that the pod on master is in beta. I didn't catch that.

I'll take a closer look. It does look nice, and having support for all those formats in one dependency is great. I'd also need to look into how to set headers, and how to preload.

There is an issue open to moving to another library already because there are some issues I have with SDWebImage: #13

I guess the most challenging thing would be determining if it's actually faster. Relevant article: https://bpoplauschi.wordpress.com/2014/03/21/ios-image-caching-sdwebimage-vs-fastimage/

[oferRounds]

Oh, cool!

[oferRounds]

@DylanVann any thoughts on this?

[tgensol]

Any news on this ? 😃

[oferRounds]

@DylanVann any new thoughts on this? I see that SDWebImage supports it (by passing SDWebImageProgressiveDownload on the options param)

[JimTeva]

Hi @DylanVann, thank you for the great library.
Could you please add SDWebImageProgressiveLoad as it is now implemented in SDWebImage here. Thank you

[romanravkov]

@DylanVann any news? we are really looking forward to :)

[tgensol]

I need to do more tests, but It looks like just by adding  SDWebImageProgressiveLoad in the SDWebImageOptions options of this file https://github.com/DylanVann/react-native-fast-image/blob/master/ios/FastImage/FFFastImageView.m (line 159) does the trick. My app seems to display progressive jpeg better

diff --git a/node_modules/react-native-fast-image/ios/FastImage/FFFastImageView.m b/node_modules/react-native-fast-image/ios/FastImage/FFFastImageView.m
index c5f79b4..fc2a601 100644
--- a/node_modules/react-native-fast-image/ios/FastImage/FFFastImageView.m
+++ b/node_modules/react-native-fast-image/ios/FastImage/FFFastImageView.m
@@ -156,7 +156,7 @@ - (void)reloadImage
         SDWebImageContext *context = @{SDWebImageContextDownloadRequestModifier : requestModifier};
         
         // Set priority.
-        SDWebImageOptions options = SDWebImageRetryFailed | SDWebImageHandleCookies;
+        SDWebImageOptions options = SDWebImageRetryFailed | SDWebImageHandleCookies | SDWebImageProgressiveLoad;
         switch (_source.priority) {
             case FFFPriorityLow:
                 options |= SDWebImageLowPriority;

[oferRounds]

I’ve tried this approach, and it didn’t work well for me. I suggest moving to PinRemoteImage – I’ve tested it as a fork of this branch on Production for a while (switched the iOS depedency), and it works great

[tgensol]

On my side it is working just as expected, so I will keep the SDWebImageProgressiveLoad