Inefficient use of heap causes frequent gc

[Nik-Gleb]

I like this library, thanks to the authors for their labor ;)
And sorry for my bad english.

In my project i have a grid of gif's (about 4x5, may be less) and today I was faced with frequent "gc-calls", and ever-growing using-heap. I discovered an issue in draw-method of gif-drawable.
mRenderTaskSchedule = mExecutor.schedule(mRenderTask, renderDelay, TimeUnit.MILLISECONDS);
Unfortunaly, java's native ScheduledThreadPoolExexcutor.schedule creates new objects, wrappers,...etc ever call

I think it makes sense to make the mRenderTaskSchedule reusable, or create any EfficientScheduledExecutor implementation, via reflections, may be jni reflections or other workarounds

Thanks.

[koral--]

Indeed, ScheduledThreadPoolExecutor#schedule() causes allocations.
Some classes from this library eg. GifTexImage2D use native (pthread) threads to change GIF frames.
It should be possible to use that mechanism also in GifDrawable. I'll check this.

[Nik-Gleb]

Ok. Perhaps it (pthread) will be more cleanest solution. Thanks.

[koral--]

Assuming that each GifDrawable will spawn its own thread. It seems that it should be additional option, not replacement of current behavior.
Adding 2.x milestone for this issue.

[Nik-Gleb]

Hi!

You can also use the Handler-based approach, to schedule decode operations.
Android already knows how to do it correctly and there is a message pool for more efficient memory using.

I think, the drawable can be free from liability by threads-managing.
The user can provide his own looper for decoding operations,
else - the MainLopper will be used by default.
mHandler = new Handler(looper);

You are also not required to return to the main thread explicitly: