When advancing multiple frames without calling getCurrentFrame(), the pixels contain artifacts. I have changed the sample app to call advance() twice before getting the frame, I got this:

The use case for this would be integrating Gif into a rendering engine where advancing frames is calculated on each frame update. If the frame rate of the engine is slower than the gif's, then advance() needs to be called multiple times in a frame resulting in this issue. Temporary workaround would be to explicitly call getCurrentFrame() after each advance() call, but I'm sure we can improve this :)

I am not sure if calling getCurrentFrame() internally when advance() is called would be the best solution, but it would fix the problem. I am not into the details of decoding, but it sounds like we need to decode frame by frame?

HI there, found another little bug :)

I was testing with lots of different gifs and downloaded some from Giphy, I found some stickers are not rendered correctly. For example this one (and others): https://media0.giphy.com/media/kayGhRlOKbJHCqnj9m/giphy.gif ends up in including the first frame when rendering the second:

I debugged a bit, this gif has 2 frames with different disposal method, the first frame being RESTORE_TO_BACKGROUND and the second DO_NOT_DISPOSE. Not sure whether that's common or not, but other tools render it correctly.

I have created a branch on my fork so you can quickly test it https://github.com/PauGuillamon/gifdecoder/commits/PGJ/car_gunna_incorrect_disposal I'm not sure what would be the best fix here, since I don't know the specs of GIF.

Let me know if I can help in any way. Thank you!

Adding a function to be able to clone a Gif. As I'm using Gif directly instead of GifDrawable, I was missing the possibility of being able to clone Gifs. With this I don't need to keep opening a file and creating new Gifs with a manually handled InputStream.

I was not sure if sharing the same InputStream between Gifs was safe or not, but I saw GifDrawable basically doing the same through GifDrawableState(). So I hope I didn't miss anything 😄

I tried keeping the same convention with a Git.from() function, but I am happy to change it in another way if you prefer.

Hi,

As I'm trying to use this library in a commercial project, can you please clarify a few things regarding licenses?

Are these benchmark files actually included in the library?

benchmark/src/main/java/com/bumptech/glide/gifdecoder/GifDecoder.kt: * Copyright 2014 Google, Inc. All rights reserved.
benchmark/src/main/java/com/bumptech/glide/gifdecoder/GifFrame.kt: * Copyright 2014 Google, Inc. All rights reserved.
benchmark/src/main/java/com/bumptech/glide/gifdecoder/GifHeader.kt: * Copyright 2014 Google, Inc. All rights reserved.
benchmark/src/main/java/com/bumptech/glide/gifdecoder/GifHeaderParser.kt: * Copyright 2014 Google, Inc. All rights reserved.
benchmark/src/main/java/com/bumptech/glide/gifdecoder/StandardGifDecoder.java: * Copyright (c) 2013 Xcellent Creations, Inc.
benchmark/src/main/java/com/bumptech/glide/gifdecoder/StandardGifDecoder.java: * Copyright 2014 Google, Inc. All rights reserved.

Is this bitmap.h file from AOSP actually used in the library?

giflzwdecoder/ndkheaders/bitmap.h: * Copyright (C) 2009 The Android Open Source Project

Any other thing I should take into account regarding the license?

Could also be helpful to clarify this in the README.md file ;)

Thank you so much!

Given android-drawable-native being currently broken, calling gradle assemble on the project fails as the cargoBuild task is missing. I'm removing this dependency.

Your FOSSA integration was successful! Attached in this PR is a badge and license report to track scan status in your README.

Below are docs for integrating FOSSA license checks into your CI:

• CircleCI
• TravisCI
• Jenkins
• Other

Explicit dependencies on kotlin-stdlib artifact are unnecessary (unless you want to specifically target a variant of the standard library).

The dependency is added automatically as you add the kotlin("jvm") plugin. Ref: https://kotlinlang.org/docs/gradle.html#dependency-on-the-standard-library

The decoder sometimes throws exception on multipl IndexOutOfBoundsExceptions:

java.lang.ArrayIndexOutOfBoundsException: 
  at net.redwarp.gif.decoder.lzw.LzwDecoder.decode (LzwDecoder.java:100)
  at net.redwarp.gif.decoder.Gif.getFrame (Gif.java:98)
  at net.redwarp.gif.decoder.Gif.getCurrentFrame (Gif.java:24)

java.lang.IndexOutOfBoundsException: 
  at java.util.ArrayList.get (ArrayList.java:437)
  at net.redwarp.gif.decoder.Gif.getFrame (Gif.java:17)
  at net.redwarp.gif.decoder.Gif.getCurrentFrame (Gif.java:24)

java.lang.ArrayIndexOutOfBoundsException: 
  at net.redwarp.gif.decoder.Gif.fillPixelsInterlaced (Gif.java:79)
  at net.redwarp.gif.decoder.Gif.fillPixels (Gif.java:6)
  at net.redwarp.gif.decoder.Gif.getFrame (Gif.java:114)
  at net.redwarp.gif.decoder.Gif.getCurrentFrame (Gif.java:24)

java.lang.ArrayIndexOutOfBoundsException: 
  at net.redwarp.gif.decoder.Gif.fillPixelsSimple (Gif.java:75)
  at net.redwarp.gif.decoder.Gif.fillPixels (Gif.java:10)
  at net.redwarp.gif.decoder.Gif.getFrame (Gif.java:114)
  at net.redwarp.gif.decoder.Gif.getCurrentFrame (Gif.java:24)

Replace self made Result class with the official kotlin.Result, now out of unstable. Also consolidate the API to use Result everywhere, instead of relying on returning null in case of error.

Implements #15 : The calculation of the frame will now occur when calling the advance() method, and getCurrentFrame will simply copy the pixel buffer. getFrame(index) will now internally call advance to make sure that each frame is processed in sequence.

So, the new flow would be: getFrame (once, twice, as many as wanted), then advance, then getframe, then advance.

With 0.4.0 comes reading the gif from a random access file. Cool. But what happens if the file gets deleted? It crashes.

It might be cool to create or reuse an exception for:

• failing to parse a file that doesn't exists
• a file that got properly parsed gets deleted before we ask to get a frame.