Support for ImageVector

[yschimke]

I'm curious if there is a reason that ImageVector is not supported?

coil/coil-compose-base/src/main/java/coil/compose/AsyncImagePainter.kt

Line 388 in 70300e5

is ImageVector -> unsupportedData("ImageVector")

Seems like a useful variant of the data type which is Any?.

[colinrtwhite]

It’s unsupported as you can render an ImageVector using Image directly.

[colinrtwhite]

@yschimke Gotcha, but the convenience would come with multiple costs:

• One frame of delay every time the composable is recomposed as the ImageVector can't be memory cached (no suitable cache key). We'll have to return it from a Fetcher, which runs on a background dispatcher, each time it's loaded.
• ImageVector/ImageBitmap can't be rendered on a standard Android/Skia canvas - they can only be drawn with Compose's DrawScope.drawImage. This doesn't play well with Coil's coil3.Image abstraction and would required some hacks to work around that.

I believe strongly that we want to nudge users to use the standard Image composable as it's faster and lets us avoid hacky code we would have to add to Coil to support this use case.

[yschimke]

Yeah, I guess genId is internal otherwise might suffice?

And for drawing without the additional bitmap caching there is no public API.

                @Suppress("INVISIBLE_MEMBER", "INVISIBLE_REFERENCE")
                with(painter.vector.root) { myCanvas.drawScope.draw() }

Yep, I take your point.

[bpappin]

@bpappin ImageVector is just Compose's abstraction on top of vector data. If you want Coil to display this data you're better off passing a reference to where the data is located to Coil (e.g. Android resource ID, file path, etc.).

Yes, I understand what it is.

There is no resource id, it's in code now.
It's a literal block of code that's compiled, so there is no external data to load.
Basically what you get in the icon pack.

It solves a lot of problems because you don't need to manage resources, especially in multiplatform.

We only use bitmaps for photos, usually loaded remotely. Any SVG or XML image vector can be converted to a compiled format.

[bpappin]

@yschimke Gotcha, but the convenience would come with multiple costs:

• One frame of delay every time the composable is recomposed as the ImageVector can't be memory cached (no suitable cache key). We'll have to return it from a Fetcher, which runs on a background dispatcher, each time it's loaded.
• ImageVector/ImageBitmap can't be rendered on a standard Android/Skia canvas - they can only be drawn with Compose's DrawScope.drawImage. This doesn't play well with Coil's coil3.Image abstraction and would required some hacks to work around that.

I believe strongly that we want to nudge users to use the standard Image composable as it's faster and lets us avoid hacky code we would have to add to Coil to support this use case.

I think the reason the comments are growing here is that Coil is operating very differently to the way we work with compose. In effect, we have to "add hacky code" into our composition.

It's like the outlier of the components in the composition, because it doesn't follow the pattern. It works, and it's a great library, but when I use it, I feel like I'm adding a legacy view component, I can't just write the composition naturally and I have to comb through documentation to figure out how to do something that should be simple (often processing an image I shouldn't need to process).

It works, and I'm sure everyone here is happy to have it, and maybe a shift in the way we think about how it works would improve it for composable layouts.

[colinrtwhite]

@yschimke That would probably work if it was public, but even then we would have one frame of delay on the first load as AsyncImage loads the image async. Also the vector would occupy space in the memory cache, which would be better reserved for images that need to be decoded and are expensive to recreate (e.g. rasterized images loaded from disk).

I don't think AsyncImage should seek to replace the standard Image composable in all cases. This is what the official Compose docs indicates as well. Images that don't need to be loaded and only need to be drawn (e.g. ImageBitmap, ImageVector, any Painter) shouldn't use AsyncImage. There are use cases where Image works much better and this is one of them.