Reduce number of rendered frames when seeking

[gregblaszczuk]

Seeking forward works really well and no frames are dropped. Now, seeking backwards is a different story. It becomes extremely jittery and drops a lot of frames.

Any idea why this is happening?

[gregblaszczuk]

This comment might help with this fix:

NOTE: all frames from current (or first one if seeking backward) to desired one must be rendered sequentially to perform seeking. * It may take a lot of time if number of such frames is large.

From my understanding, when we are seeking forward, we only render from current frame to the desired one. But when seeking back, we render from the 1st frame in the gif to the desired one. So seeking back is very costly.
The desired behavior would be to render from the current frame to the desired frame for backward seeking.

[koral--]

In general to render given frame in GIF all previous frames are needed (see here for more info: http://www.imagemagick.org/Usage/anim_basics/#dispose). In some cases desired frame can be just rendered (if there is no disposals to previous frames).
Currently it is not checked which disposal methods are used and seeking requires rendering all frames from first one to desired one to support the worst case (all frames except first one are using dispose to previous method). However it is good idea to optimize that.

[gregblaszczuk]

The gifs I am using are "do not dispose", so optimized seeking would be beneficial for those gifs.

Any thoughts on when this feature might be available?

[koral--]

I'll do it ASAP but can't promise exact time. Maybe I manage to add this feature this week.

[gregblaszczuk]

That would be awesome.Thanks!!!

[koral--]

It seems that disposal method itself doesn't say anything. Even if it is None (don't dispose) a frame may contain transparent pixels or may not cover whole canvas (as shown on linked samples). Those not covered areas contains pixels from previous frame and so on... we may end up at first frame.

The simplest optimization idea is to find nearest frame (going backwards from desired one, stopping at the current one) which is equal-sized to canvas and has no transparent pixels. All needed metadata is available without additional processing.

[koral--]

Mentioned solution can be applied if that frame uses disposal = None. Valid key frame can be also that which uses disposal to background and covers all canvas, it doesn't matter whether it has transparent pixels because we need only draw background in such case.

[gregblaszczuk]

I am not sure if the mentioned solution can be applied without modifying the library.

[koral--]

Exactly I will modify the library to reflect that change.

[koral--]

Done, available in version 1.1.16-SNAPSHOT.

[gregblaszczuk]

Any idea on when 1.1.16 will be out?
Gradle doesn't seem to support the "-SNAPCHAT" annotation.

[koral--]

It is SNAPSHOT, not SNAPCHAT. I've just added instructions how to add snapshot repository, to build.gradle to README.

It is not decided yet when 1.1.16 will be released to central repository, it should be at the beginning of may.

[gregblaszczuk]

Haha yes, I meant SNAPSHOT. Thanks!