[Image] If use a gif url, it will take more than 300m memory

[osdio]

I found the bug in the noder, if this is a bug ?

Ps: the gif size is about 1.8M

[brentvatne]

What is the memory usage on the app on the exact same screen without the gif? And with? (interested in the differential here).

[osdio]

If without gif, it only takes about 130m. But used the gif it takes 300-400m

[brentvatne]

I don't believe that anybody at Facebook is too concerned about gifs at the moment so this will need to be a community effort. Do you have any time to dig into this and try to find the cause @soliury? :smile:

[osdio]

ok, I have a try.

[nicklockwood]

It's not a bug, it's a limitation of the implementation:

Gif is a compressed format, and can't be displayed on screen directly without decompressing it. When we load a gif, we decompress all the frames and create a keyframe animation. That's why the memory consumption is so huge - every decompressed frame of the gif will take up width x height x 4 bytes, regardless of it's compressed size, so if it has a lot of frames it will be huge.

What you really want here is something like a streaming gif implementation, where frames are only decompressed as they are about to be played, rather than all in advance.

Realistically though, that's a lot of work for us to implement, since it would mean replacing the Core Animation keyframes with our own animation system based on CADisplayLink.

If possible, you'd be better off using a video instead of a gif for a long animation like this.

[sophiebits]

Probably easiest to just write a wrapper for https://github.com/Flipboard/FLAnimatedImage (which Facebook uses in some of its apps).

[osdio]

@nicklockwood @spicyj ok, I see. I'll have a try

[aleclarson]

What's the status on this? I'd really like a performant GIF implementation. :grin:

[midudev]

+1

[ide]

There's a good chance that Facebook doesn't have a need for animated GIFs especially if they transcode to a movie format on the server. As @spicyj suggested, making a module that uses FLAnimatedImage is probably easiest and best if you need GIF support.

[cosmith]

I think gifs work fine now. Trying the bot :wink:

[cosmith]

@facebook-github-bot close

[facebook-github-bot]

@cosmith tells me to close this issue. If you think it should still be opened let us know why.

[nicklockwood]

We've not changed the GIF implementation, so I doubt this situation has improved. Small GIFs work fine (as they always have), large GIFs will probably still cause an OOM.

[cosmith]

@facebook-github-bot reopen

[facebook-github-bot]

Okay, reopening this issue.

[oblador]

@nicklockwood: Would you accept a PR using FLAnimatedImage?

[mkonicek]

@oblador I don't think we want to add a dependency on https://github.com/Flipboard/FLAnimatedImage. Also all of the RN Obj-C source code is published to npm and don't think we have any way to specify dependencies like we do on Android.

Can you release a wrapper for FLAnimatedImage a separate RN module?

[oblador]

@mkonicek: Yeah maybe it makes sense to release it as a community module and that's been my approach so far, only downside is that I'd have to do a semi-fragile extension sniff on url in JS instead of inspecting file headers and lots of code duplication from core. But performance is really several magnitudes better though, so it would still be nice to have something better in core since the current implementation is almost unusable for anything large or non-trivial.

FLAnimatedImage dependency could be included via a submodule and then strip out anything but the good stuff via npmignore. But that's not ideal ofc and cocoapods I assume is not an option.

[nihgwu]

any news about this? the force-close problem caused by large gif file is really frustrating me

[nihgwu]

I've published a FLAnimatedImage wrapper to npm https://github.com/nihgwu/react-native-flanimatedimage I've been using it in production for quite a long time.

[lacker]

^ That seems like a good solution, if you need large gifs then FLAnimatedImage rather than adding this to the built-in image seems like the way to go. I'm going to close this issue, thanks everyone for helping out!