Found in the hands-on acceptance test of next (092176d), #356. A decision for sneak.
What it is
pixa (https://git.eeqj.de/sneak/pixa) serves an animated GIF or animated WebP as a still image of its first frame. That holds in every output format, orig included. The client is not told, and the README never mentions animation. Nothing in the code chooses this: libvips loads only the first frame unless asked for all of them.
Example: a three-frame animated GIF at https://cdn.example.com/spinner.gif, requested as /v1/image/cdn.example.com/spinner.gif/60x45.gif, comes back as a one-frame GIF. The same happens for .webp and .orig, and for an animated WebP source.
Options
Keep animation: GIF and WebP output keep every frame, each resized. JPEG, PNG, AVIF and JPEG XL output keep the first frame, and the README says so.
Cost: memory and encode time grow with the frame count. The existing size limits would have to count every frame, or a GIF of hundreds of frames could exhaust memory. A moderate change in internal/imageprocessor, with tests.
First frame, documented: keep today's behaviour, and say in the README that pixa serves the first frame of an animated image. No code change.
Recommendation
Keep animation. Animated GIFs are common on web pages, and a site owner expects one to stay animated. Today it silently stops moving.
Should this be built?
Model: opus-5-5
Found in the hands-on acceptance test of `next` (`092176d`), https://git.eeqj.de/sneak/pixa/issues/356. A decision for sneak.
## What it is
pixa (https://git.eeqj.de/sneak/pixa) serves an animated GIF or animated WebP as a still image of its first frame. That holds in every output format, `orig` included. The client is not told, and the README never mentions animation. Nothing in the code chooses this: libvips loads only the first frame unless asked for all of them.
Example: a three-frame animated GIF at `https://cdn.example.com/spinner.gif`, requested as `/v1/image/cdn.example.com/spinner.gif/60x45.gif`, comes back as a one-frame GIF. The same happens for `.webp` and `.orig`, and for an animated WebP source.
## Options
- **Keep animation**: GIF and WebP output keep every frame, each resized. JPEG, PNG, AVIF and JPEG XL output keep the first frame, and the README says so.
- Cost: memory and encode time grow with the frame count. The existing size limits would have to count every frame, or a GIF of hundreds of frames could exhaust memory. A moderate change in `internal/imageprocessor`, with tests.
- **First frame, documented**: keep today's behaviour, and say in the README that pixa serves the first frame of an animated image. No code change.
## Recommendation
**Keep animation**. Animated GIFs are common on web pages, and a site owner expects one to stay animated. Today it silently stops moving.
Should this be built?
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found in the hands-on acceptance test of
next(092176d), #356. A decision for sneak.What it is
pixa (https://git.eeqj.de/sneak/pixa) serves an animated GIF or animated WebP as a still image of its first frame. That holds in every output format,
origincluded. The client is not told, and the README never mentions animation. Nothing in the code chooses this: libvips loads only the first frame unless asked for all of them.Example: a three-frame animated GIF at
https://cdn.example.com/spinner.gif, requested as/v1/image/cdn.example.com/spinner.gif/60x45.gif, comes back as a one-frame GIF. The same happens for.webpand.orig, and for an animated WebP source.Options
internal/imageprocessor, with tests.Recommendation
Keep animation. Animated GIFs are common on web pages, and a site owner expects one to stay animated. Today it silently stops moving.
Should this be built?
Model: opus-5-5