coil-kt/coil

Support Skiko SVG rendering on Android

Open

#3.090 geöffnet am 23. Juli 2025

Auf GitHub ansehen
 (6 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)Kotlin (757 Forks)batch import
enhancementhelp wanted

Repository-Metriken

Stars
 (11.779 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 20h 14m) (28 gemergte PRs in 30 T)

Beschreibung

Is your feature request related to a problem? Please describe. Our default Android SVG renderer, androidsvg, is a common pain point with coil-svg as it's more prone to rendering issues compared to our non-Android SVG renderer, Skiko. We use androidsvg as it's completely written in Java with no native libraries so it's impact on binary size is very small. Skiko, on the other hand, uses native libraries that increase the binary size by megabytes. That said, we should figure out a better story for users who need to fix the rendering issues introduced by androidsvg without writing our own custom SVG parser (a giant undertaking).

Describe the solution you'd like Coil 3.3.0 exposes a new Svg.Parser interface. Given we already support Skiko and androidsvg implementations of this interface, I propose we separate out our Skiko SVG renderer into a new module so folks who want to use it and don't care about the increased binary size can do something like this to use Skiko instead of androidsvg on Android:

val ImageLoader.Builder(context)
    .components {
        // Skiko is just a Kotlin wrapper for Skia.
        add(SvgDecoder.Factory(parser = SkiaSvg.Parser())
    }
    .build()

Additional context This may or may not actually work given I'm not sure how well Skiko supports Android and Compose Multiplatform (and Coil) only uses Skiko on non-Android platforms. Also Skiko uses a different set of bitmap classes that we'll have to translate to Android bitmaps. There's also no timeline to release this. Also if someone wants to take a shot at this, PR welcome!

Contributor Guide