You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To work around #301, we banned Bitmaps with configs other than ARGB_8888 from being placed into the BitmapPool and defaulted to always requesting ARGB_8888 Bitmaps.
Unfortunately the framework doesn't always obey inPreferredConfig. GIFs in particular almost always produce Bitmaps with null (hidden) configs.
Since those Bitmaps are banned from the pool, apps displaying a mix of single frame GIFs and other content will end up with a net drain on the BitmapPool, causing jank.
From some limited testing it appears safe to re-use ARGB_8888 Bitmaps to decode single frame GIFs, and to re-use Bitmaps with null configs to decode most image types with inPreferredConfig == ARGB_8888.
The text was updated successfully, but these errors were encountered:
To work around #301, we banned Bitmaps with configs other than ARGB_8888 from being placed into the BitmapPool and defaulted to always requesting ARGB_8888 Bitmaps.
Unfortunately the framework doesn't always obey inPreferredConfig. GIFs in particular almost always produce Bitmaps with null (hidden) configs.
Since those Bitmaps are banned from the pool, apps displaying a mix of single frame GIFs and other content will end up with a net drain on the BitmapPool, causing jank.
From some limited testing it appears safe to re-use ARGB_8888 Bitmaps to decode single frame GIFs, and to re-use Bitmaps with null configs to decode most image types with inPreferredConfig == ARGB_8888.
The text was updated successfully, but these errors were encountered: