The weird layout issue caused when tapping a username in the comments.
GIFs will no longer be automatically rendered as animated images anywhere in the app, except when opening the image viewer.
I want to give a bit more context about 2.
GIFs (and animated WebP images) have been the most common cause of crashes and UI freezes in Bean. The last couple of days have been particularly bad as this image of the Lemmy version of r/place has been shared.
This image is 12.4MB, animates for over 2 minutes, and (most importantly) is almost 3,000 frames. I can’t even tell you exactly how many frames as both Preview and Photoshop froze on my Mac when trying to open the image.
The reason the number of frames is important, because a GIF is just a container for multiple images. Each frame is an individual image that needs to be decoded and rendered on the screen, and it turns out when there are a lot of them at 1000 x 1000px it is impossible to decode performantly.
Bean uses SDWebImage to download, cache, and render images behind the scenes. It’s a fantastic library that is the de facto standard when working with remote images on iOS or macOS. Even with the progressiveLoad and scaleDownLargeImages options enabled, SDWebImage just cannot render certain images without iOS sounding the alarm and firing an OOM exception — especially when that image is 12.4MB and 3,000 frames.
At the moment, Bean will crash if you attempt to open this image. I have even tried working around this and rendering it in a web view, or using another library — FLAnimatedImage. Neither of these solutions worked and believe me, I’m not happy about that (seriously, I really hate GIFs now).
In the coming days, I’ll be pushing another update that will check for the size of the image before deciding whether to animate it or not. When not animated, SDWebImage only decodes the first frame of a GIF which is no issue at all.
I know this isn’t brilliant, as in the ideal world every image would be viewable within Bean, but it’s the best solution I can think of to avoid a single image crashing the app.
A couple more fixes are incoming:
I want to give a bit more context about 2.
GIFs (and animated WebP images) have been the most common cause of crashes and UI freezes in Bean. The last couple of days have been particularly bad as this image of the Lemmy version of r/place has been shared.
This image is 12.4MB, animates for over 2 minutes, and (most importantly) is almost 3,000 frames. I can’t even tell you exactly how many frames as both Preview and Photoshop froze on my Mac when trying to open the image.
The reason the number of frames is important, because a GIF is just a container for multiple images. Each frame is an individual image that needs to be decoded and rendered on the screen, and it turns out when there are a lot of them at 1000 x 1000px it is impossible to decode performantly.
Bean uses SDWebImage to download, cache, and render images behind the scenes. It’s a fantastic library that is the de facto standard when working with remote images on iOS or macOS. Even with the
progressiveLoadandscaleDownLargeImagesoptions enabled, SDWebImage just cannot render certain images without iOS sounding the alarm and firing an OOM exception — especially when that image is 12.4MB and 3,000 frames.At the moment, Bean will crash if you attempt to open this image. I have even tried working around this and rendering it in a web view, or using another library — FLAnimatedImage. Neither of these solutions worked and believe me, I’m not happy about that (seriously, I really hate GIFs now).
In the coming days, I’ll be pushing another update that will check for the size of the image before deciding whether to animate it or not. When not animated, SDWebImage only decodes the first frame of a GIF which is no issue at all.
I know this isn’t brilliant, as in the ideal world every image would be viewable within Bean, but it’s the best solution I can think of to avoid a single image crashing the app.