DEV Community: Sutaek Oh

Fixing Animated WebP Jitter on Android with Jetpack Compose

Sutaek Oh — Thu, 29 Jan 2026 02:10:36 +0000

Have you ever noticed some animated WebP images jittering by about 1 pixel on Android? It’s subtle, but it becomes obvious once you notice it. This post covers why it happens and how to fix it.

1px jitter visible on grid lines

In my testing, this issue reproduced on Android 15 and earlier, but not on Android 16 (tested on emulator and Samsung Galaxy S23+). However, many users are still on older OS versions, so this workaround remains relevant. A repro asset is included at the end of this post if you want to test it yourself.

The Problem

I was displaying animated WebP images in an app when I noticed them shaking slightly — about 1 pixel. It only happened at certain downscaled sizes, and the same image displayed normally in Chrome on the same device.

In our production setup, this issue is common. Design assets are typically exported at higher resolutions than their display size, and most animations are delivered as animated WebP. So downscaling is almost always involved.

Root Cause Analysis

This happens when animated WebP is decoded via ImageDecoder (Android 9+) into AnimatedImageDrawable — the common setup for Coil and Glide.

After digging in, I found the issue occurs when two conditions are met:

The animated WebP uses partial frames
The image is scaled at a non-integer ratio (e.g., 0.7x, 0.8x)

What Are Partial Frames?

Animated images can store frames in two ways:

Full frames: Every frame contains the complete image.
Partial frames: Only the changed region relative to the previous frame is stored.

Partial frames (or delta frames) reduce file size, so they’re often the default. Each one also includes coordinates (offset) like “draw this patch at position (x: 100, y: 100).”

Why Non-Integer Scaling Causes Problems

Since Android generally handles image placement coordinates in integer pixel units, the renderer must round scaled coordinates to integers. The problem is that partial frames can have slightly different offsets, and rounding errors vary depending on the scale ratio.

For example, at 0.7x scaling with offsets that shift by 2px each frame (100 → 102 → 104 → 106):

100 × 0.7 = 70.0 → 70
102 × 0.7 = 71.4 → 71
104 × 0.7 = 72.8 → 73 ← skips 72
106 × 0.7 = 74.2 → 74
Rendered positions: 70 → 71 → 73 → 74 (irregular spacing causes jitter)

This manifests in two ways:

Jittering/Shaking: The partial frame position shifts by 1 pixel between frames, making the image appear to vibrate.
Gray lines/Seams: A thin gray line where the image was cut and reassembled. Both symptoms have the same root cause, so the fix is identical.

The Solution

Assuming you’re using Coil with Jetpack Compose. If you don’t override size, Coil resolves the request size from the destination constraints and passes it to ImageDecoder. The jitter only reproduced when decoded at a scaled size.

The fix is simple — decode at original size (Size.ORIGINAL), and let Compose handle the scaling to fit your layout constraints:

@Composable
fun WebpImageWithWorkaround(
    model: Any,
    contentDescription: String?,
    modifier: Modifier = Modifier,
) {
    AsyncImage(
        model = ImageRequest.Builder(LocalContext.current)
            .data(model)
            .size(Size.ORIGINAL)
            .precision(Precision.EXACT)
            .build(),
        contentDescription = contentDescription,
        modifier = modifier,
    )
}

Fixing Scaling Quality Degradation

The above workaround fixes the jitter, but there’s a catch: scaling quality can degrade on some devices.

By decoding at Size.ORIGINAL, scaling shifts to the draw path of AnimatedImageDrawable, and the filtering quality can be noticeably worse. I tried a few common quality-tuning knobs, but none made a difference.

Quality loss with first workaround

To fix the quality issue, render at original size into an offscreen layer first, then scale the layer output via GPU:

@Composable
fun WebpImageWithWorkaround2(
    model: Any,
    contentDescription: String?,
    modifier: Modifier = Modifier,
) {
    Box(modifier = modifier.scaledLayout()) {
        AsyncImage(
            model = ImageRequest.Builder(LocalContext.current)
                .data(model)
                .size(Size.ORIGINAL)
                .precision(Precision.EXACT)
                .build(),
            contentDescription = contentDescription,
            modifier = Modifier.graphicsLayer(compositingStrategy = CompositingStrategy.Offscreen),
            // ContentScale and Alignment must now be handled manually in scaledLayout().
            // For simplicity, this example assumes ContentScale.Fit and Alignment.Center.
            contentScale = ContentScale.None,
            alignment = Alignment.TopStart,
        )
    }
}

fun Modifier.scaledLayout() = layout { measurable, constraints ->
    // Measure with unbounded constraints to ensure 
    // the image is drawn at its original size.
    val placeable = measurable.measure(Constraints())

    if (placeable.width <= 0 || placeable.height <= 0) {
        return@layout layout(constraints.minWidth, constraints.minHeight) {}
    }

    val scale = minOf(
        constraints.maxWidth.toFloat() / placeable.width,
        constraints.maxHeight.toFloat() / placeable.height,
    )

    val scaledWidth = (placeable.width * scale).roundToInt()
    val scaledHeight = (placeable.height * scale).roundToInt()

    layout(scaledWidth, scaledHeight) {
        placeable.placeWithLayer(0, 0) {
            scaleX = scale
            scaleY = scale
            transformOrigin = TransformOrigin(0f, 0f)
        }
    }
}

With CompositingStrategy.Offscreen, the drawable renders into an offscreen buffer, and scaledLayout() ensures it renders at original size by passing unbounded constraints. Then placeWithLayer() applies GPU-accelerated scaling to the buffer output, bypassing AnimatedImageDrawable's low-quality draw-time scaling.

Left: Default AsyncImage (1px jitter). Right: Workaround applied (stable + clean).

In production, you may want to skip this workaround on Android 16+ where I couldn’t reproduce the issue.

Trade-offs

This solution uses somewhat more memory — you’re decoding at original size, plus maintaining a full-size offscreen canvas. It also adds GPU overhead from offscreen rendering and scaling. However, in my testing on lower-end devices, I didn’t observe any noticeable performance impact. It’s a reasonable trade-off for smooth animations.

Repro Asset

Valid asset; jitter is scenario-dependent (non-integer scaling).

ImmutableList vs. List in Jetpack Compose: Rethinking “Best Practice” After Strong Skipping Mode

Sutaek Oh — Wed, 21 Jan 2026 14:15:23 +0000

Before Strong Skipping Mode [1] became the default, it was widely considered best practice in Compose to prefer immutable collections (e.g., kotlinx ImmutableList<T>) over unstable collections like List<T> for stability and better skipping behavior.

With Strong Skipping Mode now being the default, the situation has changed. In most real-world screens, immutable collections don't automatically outperform unstable ones - in many cases they provide little to no performance benefit, and can even become pure overhead due to conversion and equality costs.

Case-by-Case Analysis

To make this discussion concrete, I'll compare ImmutableList<T> and List<T> across three common cases.

In most Android apps, data from Retrofit, Ktor, Room, or similar libraries usually comes as List<T>. So using ImmutableList<T> for Compose stability typically means calling toImmutableList().

With that in mind, this post assumes:

List<T> is not backed by a MutableList<T> that is mutated from elsewhere.
ImmutableList<T> is created via toImmutableList().

Also, this post only discusses Compose skippability, not the architectural benefits of immutable collections.

Case 1. The list never changes (always the same instance)

If your list never changes and you keep the exact same instance, List<T> and ImmutableList<T> behave almost the same in practice: both end up with the cost of an instance equality check (===).

Though ImmutableList<T> still has an O(N) conversion cost (e.g., toImmutableList()), it's usually negligible since you do it only once in this case.

Case 2. The list instance changes only when the content actually changes

In this scenario, using ImmutableList<T> adds extra work: you pay a conversion cost to build it, and you also pay an O(N) object equality cost (structural equality, == or equals()) when Compose compares the new parameter to the previous one. Since you need to recompose anyway, that extra work is pure overhead - and List<T> avoids both costs.

Case 3. The content doesn't change, but a new list instance is created frequently

This is the one case where ImmutableList<T> can actually help. If you keep recreating List<T> instances with the same content, Compose will treat the parameter as changed because the instance equality check fails. With ImmutableList<T>, Compose can use object equality to recognize "same content" and skip work higher up the composition tree.

The catch is the cost: equals() for lists is O(N), and you’re also paying the conversion cost upfront. If most of the UI work is already isolated in skippable leaf composables, these costs are sometimes harder to justify than just letting List<T> flow down and relying on skipping at the leaf — especially with lazy composables like LazyColumn.

And there's another catch: instance changes without content changes can sometimes be filtered upstream, turning Case 3 into Case 2 - for example, using StateFlow<T> in your ViewModel. Details are in the Appendix.

So even in this case, ImmutableList<T> isn't an automatic win.

Conclusion

If your concern is skippability, there’s no need to convert List<T> coming from your data sources — the old assumption that "unstable = always bad" no longer holds. Still, ImmutableList<T> can sometimes be worth the overhead for better skippability — and it may offer architectural benefits beyond what this post covers. So if you’re already using it, there's no reason to switch back to List<T> either. Don’t worry too much upfront. It's enough to optimize when you see a real bottleneck.

Remember: not every composable should be skippable. [2] And not every list needs to be ImmutableList<T>.

Appendix. Case-by-Case Details

Case 3–1. Lazy composables

With lazy composables like LazyColumn, it’s easy to overestimate what you save by skipping higher up. Even if the parent recomposes, actual work is still bounded by the visible range, rather than scaling with the total list size. In that setup, paying O(N) for equals() and conversion can outweigh the work saved by higher-level skipping.

Case 3–2. `StateFlow<T>` and upstream filtering

StateFlow<T> has distinctUntilChanged() built-in: if the new value equals the current one, it doesn't emit and keeps the existing instance. So if you call update { it.copy(list = ...) } with the same content and nothing else changed, StateFlow<T> won't emit - the original list instance stays intact. This effectively turns Case 3 into Case 2. Thus, in this scenario, List<T> saves a conversion cost and an object equality check cost as described in Case 2.

Note: StateFlow<T> doesn't eliminate Case 3 entirely. For example, if you call update { it.copy(list = newInstance, isLoading = false) } and only isLoading actually changed, StateFlow<T> will emit because T.equals() returns false - and the new list instance gets delivered anyway.