Dynamic Image Formats and Performance Comparison on Android

Abstract

This article introduces the definition, history, terminology, and current status of dynamic images, compares the main formats, and provides a performance comparison between GIF and WebP on the Android platform to guide technology selection.

1. Overview

1.1 What is a Dynamic Image?

Dynamic image formats are extensions of static image formats that encode frame‑by‑frame animation. Compared with video streams, dynamic images have simpler encoding rules, no fixed frame rate, and are suitable for a small number of frames with complex inter‑frame relationships.

"Emoji" is a typical business use case of dynamic images, featuring few frames and complex inter‑frame relations.

1.2 History and Current Situation

The earliest dynamic image technology, represented by GIF89a, appeared in the late 1980s. GIF introduced concepts such as variable frame rate and per‑frame area, which later formats borrowed.

GIF contributed greatly to early web animations but suffers from limited color depth, low compression, and other constraints.

Flash emerged in the late 1990s as a richer alternative, but its high power consumption and security issues caused it to fade away with the rise of mobile devices.

Subsequent “next‑generation” formats include Motion JPEG, MNG, APNG, WebP, and sharpP. Google‑led WebP has the strongest momentum, especially on Android, yet adoption varies across browsers and platforms.

1.3 Terminology and Concepts

1.3.1 Frame

A frame is a single static image within a dynamic image sequence. It stores image data, display duration, and other metadata.

1.3.2 Position, Size, Delay, Loop Count

Each frame can define its own position and size within the canvas, a delay time before the next frame, and the number of times the whole sequence repeats.

1.3.3 Alpha Blending and Disposal Method

Alpha blending controls semi‑transparent rendering; disposal method specifies how a frame should be treated when the next frame is shown.

Alpha blending configurations and meanings

Disposal method configurations and meanings

1.3.4 Example

A traffic‑light GIF illustrates how frame a defines the background and frame b stores only the changed region. With a disposal method of “overlay”, the final appearance matches frame c.

2. Common Dynamic Image Formats

2.1 GIF

2.1.1 Frame Encoding

2.1.1.1 Palette and Color Quantization

GIF uses a palette (max 256 colors) and stores pixel data as indices, reducing file size. Color quantization selects the most representative colors, often using octree or error‑diffusion algorithms.

2.1.1.2 LZW Compression

LZW builds a dictionary of repeated color indices for lossless compression. The dictionary is generated during encoding and reconstructed during decoding.

2.1.2 Transparency and Animation Features

GIF supports a single transparent color but no alpha channel. It can implement all features described in Section 1.3 except alpha blending.

2.1.3 File Structure

GIF files consist of a logical header followed by a series of blocks whose lengths determine their positions.

2.2 APNG

APNG, introduced in 2004 by the Mozilla community, extends PNG with animation chunks. It is not an official PNG standard.

Supported on iOS 8+ Safari, Chromium (upcoming), but not natively on Android.

APNG retains full PNG transparency and supports all dynamic‑image features listed in Section 1.3.

2.3 WebP

2.3.1 Overview

Google released WebP in 2010; dynamic support arrived in 2011 and lossless support in 2012. WebP aims to reduce file size without sacrificing quality, using VP8 for lossy and a custom algorithm for lossless compression.

Android native support: lossless from 4.3 onward; Chrome 32+ supports animated WebP.

2.3.2 Frame Encoding

2.3.2.1 Block Prediction

Frames are divided into 4×4 macro‑blocks. Each block can be predicted from neighboring blocks, and only the prediction mode is stored.

2.3.2.2 Adaptive Block Quantization

Up to four regions can be defined, each with its own compression parameters, allowing finer control over complex versus simple areas.

2.3.3 Transparency and Animation

WebP fully supports an alpha channel. In lossy WebP the alpha data is stored in a separate chunk, which can be independently optimized.

2.3.4 File Structure

WebP uses the RIFF container. Each RIFF chunk contains a four‑character identifier, size, and payload, and chunks may be nested.

3. Performance Comparison on Android

Using the FrameSequence library, GIF and WebP were decoded via libgif and libwebp respectively. Tests varied frame rate, resolution, device model, and concurrent instance count.

3.1 Frame Rate & Resolution

Higher frame rates increase CPU usage but do not affect file size or memory. Higher resolution significantly impacts file size, load time, and memory.

3.2 Format Comparison (GIF vs WebP)

File size: WebP < GIF.

Load time: WebP considerably faster.

CPU usage: WebP consumes more CPU due to heavier decoding.

The higher CPU cost of WebP stems from FrameSequence decoding each frame on the fly, whereas GIF decoding is lighter.

3.3 Device Model

Higher‑end devices load faster and use less CPU; device differences should be considered when deploying animated images.

3.4 Concurrent Instances

Increasing the number of simultaneously playing animations raises memory, CPU, and load time proportionally.

3.5 Overall Conclusions

CPU consumption is the most critical performance factor; WebP is more CPU‑intensive.

WebP wins on file size and load speed, making it suitable for bandwidth‑constrained scenarios.

Control the number of concurrent animations and recycle drawables properly.

4. Final Recommendation

GIF remains the safest choice for maximum compatibility and low CPU cost. APNG and WebP offer better compression and quality; WebP shows the strongest future potential, especially on Android, and may become the preferred format for dynamic images.

References

GIF specifications, LZW encoding, animation & transparency docs, octree quantization article, WebP official documentation, Android FrameSequence source code, etc.