Proposal: GIF support as plugable module

[stepango]

Gif support increase lib size as well as methods count and compilation time. Mostly apps don't need GIF support.
Also pluggable modules approach could simplify glide-core codebase and speed up GIF-related fix releases as well as simplify adding support for new formats such as progressive jpeg or webm for earlier android versions.

[TWiStErRob]

Historically (v3) GIF needed to be baked in because of how transcoding worked. There was a GifBitmapWrapper that handled either a normal or a GIF drawable. It looks like in v4 all the GIF logic is separated out into the .resource.gif package. It is likely independent now, so your proposal can be implemented.

Progressive JPEG and WebM integrations can be done regardless of separating GIF out, you just need a few supporting classes (decoder, transcoder) and then use them in a load. They could be done by any independent parties, in a similar manner to https://github.com/wasabeef/glide-transformations.

All of these are nice ideas, but may be not that pressing. Most of the it's time easier to change to the URL to return a jpeg instead of a webp on the server side; and ProGuard will get rid of your extra classes and methods.

That said, I think if anyone makes a PR for any of these, it'll be happily accepted by @sjudd.

[sjudd]

Yup I agree, I'd definitely accept pull requests.

[svenjacobs]

I was about to write the same. Method count should be reduced. The current version of Glide adds 2879 methods whereas Picasso only adds 849. I'm aware that Glide has more functionality but especially something like GIF support could be moved to an optional module. I've seen that synthetic accessor methods have already been removed. Good work! :)

[TWiStErRob]

@svenjacobs do those numbers hold up after ProGuarding as well?

[svenjacobs]

@TWiStErRob In our application Glide retains 1668 methods after ProGuard. We don't use GIF loading and we use the ProGuard configuration specified here.