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
Then the decode fails. As A8 images are extremely rare, this hadn't come up before. However, with the addition of gainmap images the usage of A8 "images" became much more common as a common space/quality tradeoff for the gainmap is to use a8 and provide only luminance modulation as a result. In this scenario it becomes quite possible for all 4 of the above conditions to be hit.
However, it is rather easy to both detect the presence of the bug (simply try to copy an A8 bitmap to Config.HARDWARE - if null is returned the bug is present) and to workaround it in a decently efficient means by simply decoding to non-hardware first, converting the A8 gainmap to 8888, and then copying the result to HARDWARE and returning that. This is not dissimilar to how decoding directly to HARDWARE works, so performance impact should be minimal. See the Glide implementation of both here: bumptech/glide#5357
If nothing is done about this then the failure mode is simply that the decoding of the gainmap portion fails, but the primary image is still successfully returned. As in, the behavior simply matches what Android T did, prior to the introduction of gainmaps. So the failure mode is quite forgiving.
The text was updated successfully, but these errors were encountered:
to a Config.HARDWARE output and check that bitmap#getGainmap() returns non-null. You can force this failure path on a pixel device by first doing adb shell setprop debug.hwui.renderer skiagl (kill & re-launch the app to pick up the setting change)
Prior to Android V there exists a bug where when:
Then the decode fails. As A8 images are extremely rare, this hadn't come up before. However, with the addition of gainmap images the usage of A8 "images" became much more common as a common space/quality tradeoff for the gainmap is to use a8 and provide only luminance modulation as a result. In this scenario it becomes quite possible for all 4 of the above conditions to be hit.
However, it is rather easy to both detect the presence of the bug (simply try to copy an A8 bitmap to Config.HARDWARE - if null is returned the bug is present) and to workaround it in a decently efficient means by simply decoding to non-hardware first, converting the A8 gainmap to 8888, and then copying the result to HARDWARE and returning that. This is not dissimilar to how decoding directly to HARDWARE works, so performance impact should be minimal. See the Glide implementation of both here: bumptech/glide#5357
If nothing is done about this then the failure mode is simply that the decoding of the gainmap portion fails, but the primary image is still successfully returned. As in, the behavior simply matches what Android T did, prior to the introduction of gainmaps. So the failure mode is quite forgiving.
The text was updated successfully, but these errors were encountered: