Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Image] If use a gif url, it will take more than 300m memory #1968
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.
@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?
@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