CacheControl.NONE cache stategy is not support yet. about glidewebpdecoder HOT 4 CLOSED

另外设置策略为ALL的话，隐藏的问题就是如果播放的数量太多，帧数又太多的话，8.0之前bitmap是放在java heap的，肯定比较容易溢出

from glidewebpdecoder.

@YouheiLee bitmap cache in webpdecoder has another function. When rendering an non-key frame, it is based on the nearest key-frame previous rendered and the cache will be useful. Otherwise we need render from last key-frame again to get current frame bitmap and performance will be low. And min cache size set to 5 with CACHE_NONE is a reasonable assumption that hit the cache to render a new frame with high possibility.
CACHE_ALL is just an option control to decide by app when you don't want to reuse glide cache. It is single request configuration and how to control memory usage is all totally decided by caller.

from glidewebpdecoder.

I think that we do not need cache bitmap with a specific number like 5. Consider that we have 20 frame in a webp image, cache 5 bitmap is useless, every time we will need obtain a new bitmap object from bitmap pool instead lru cache defined at WebpDecoder cause the right index will never be hit. So there are only two ways left: 1. only cache the last key frame; 2. cache all frame.

from glidewebpdecoder.

The cached bitmap was used to render current bitmap and right index not hit was expected. If current frame is not key frame, the decoded bitmap is not full. We must fill the canvas with previous frame data according to webp rendering principle. Only cache the last key frame is not suitable and might cause extra frame decoding.

For example, with a webp has 20 frame, and frame 1, 5, 10, 15 are key frames. Assume current frame index to render is 4, If you only cache the last key frame that means it is 1. To get the full bitmap of frame 4, we need decode frame 2, frame 3 again. Because frame 4 bitmap = frame1 + frame2 + frame3 + frame4. But if we cache frame 3 (non-key frame) and it meet the condition, and so we no need to decode frame 3 again, because frame 4 bitmap = frame3 + frame4.

@YouheiLee you should understand prepareCanvasWithBlending() and next for-loop. renderFrame() with native call might call many times without previous frame cache. And that is the main purpose of 5 cache. Why we not only cache the one frame before current frame, because sometimes it not always meet conditions in prepareCanvasWithBlending()

from glidewebpdecoder.