Add GIF support for animated lock screen

[sh1r4s3]

Description

Use gif_lib to read a GIF file and show animated lock screen. Currently it supports only 0-2 disposal methods.

Screenshots/screencaps

Release notes

Added support for animated GIF images.

[Raymo111]

@sh1r4s3 Can you fix the build files as well?

[sh1r4s3]

@Raymo111 I updated the Dockerfile to include libgif-dev package that should contain gif_lib.h as well as the shared lib. Also I updated configure.ac to check that gif_lib.h exists. Could you please trigger the workflow to test those changes?

[sh1r4s3]

@Raymo111 From the build log it is seems that it doesn't use an updated version of travis/Dockerfile. Not sure why... Maybe it fetches this Dockerfile from the different branch or just uses the cached image.

[Raymo111]

@sh1r4s3 oh we're not using Travis... Upstream used to use it but they switched to GitHub Actions recently and we've been using GitHub Actions for a while now. You'll want to edit the .github/ files

[sh1r4s3]

@Raymo111 got it, thanks! I updated these files. Could you please trigger the build again :)

[sh1r4s3]

@Raymo111 seems that now everything is OK :)

[Raymo111]

Currently it supports only 0-2 disposal methods.

Btw @sh1r4s3 What did you mean by this?

[sh1r4s3]

@Raymo111 Thanks for the review! I implemented your suggestions and updated the man page.

Also, mind explaining what read_gif_image does?

Sure. Basically it do the following:

1. Open a GIF file and read it to the buffer. gif_lib would parse the header so we can now extract some info like width/height of the canvas.
2. Next we want to calculate the stride value which the cairo lib will use. The stride is the distance in bytes from the beginning of one row of the image data to the beginning of the next row.
3. The next step is to read frames (images) from the GIF file. In the loop we do: 3.1. Create a cairo surface. 3.2. Read the Graphics Control Extension (paragraph .23) to extract the delay value. The delay value is the time in [ms] before switch to the next frame. 3.3. Next we read the size of the frame's image and the color map. 3.4. Read the disposal mode. Generally in GIF, currently, we have 4 disposal modes: 0 - No disposal specified; 1 - Do not dispose; 2 - Restore to background color; 3 - Restore to previous. Usually, AFAIK, only 0-2 are used. What does it means, e.g., we have 1 (Do not dispose) and we have some animation. The first frame is a background of the animation. The second frame contains mostly transparent pixels and a part of the rain drops, it would be written "on top" (basically replace pixels from the previous background image) of the previous image. The next frame contains the same, but the rain drops are in the new positions and on the places of the "old" rain drops there will be parts of the background image. And so on. The reason why I didn't implement the third disposal mode is that it uses very rarely and it is a little bit tricky to implement.

[sh1r4s3]

Also I think it is worth to mention that this code doesn't upscale GIF images. A user should find a gif file that suits its display's resolution or upscale it with the of other utility, like convert from ImageMagick (the way I use this code).

[sh1r4s3]

Hi @Raymo111, I just wanted to kindly remind about this PR :)