I want to use Coroutines Flow to generate Thumbnails from images, but I'm not sure which Flow is the correct one to use. So my idea was to send images that need to be processed to a Channel and read from that with channelFlow() ... but since Channels are hot they seem to be a bad idea (after watching the KotlinConf2019 talk). I want to send a URL to a flow somehow and receive the ImageBitmap back. The first flow should read images from disk one after another, feed them to multiple coroutines that process thumbnails and send that back to the caller. How to do that?

Why do you want to use a flow? It seems to me that you have an input of an image, and want its thumbnail, many times, which fits a normal suspending function:

suspend fun Image.createThumbnail() {
  // Your logic here
}

Then when you have that, you can use normal flows if you want to, but I don't see any benefits (or maybe I didn't understand your objective) :

val thumbnails = flowOf(image1, image2, ...)
  .map { it.createThumbnail() }

I want to use the flow to construct a pipeline where I feed URLs into it (for the images that become visible as the user scrolls trough a gallery grid) and just load them - one after another.

I don’t think your use-case is a good fit for a Flow, either hot or cold. Unlike traditional threads, Coroutines are designed to be able to spawn many hundreds, thousands, or even millions of concurrent jobs, and you could very easily launch a new job for each image in the grid. I think some of your confusion is not fully understanding the differences and use-cases of hot vs cold flow. A cold Flow is not necessarily a pipeline of data, but more accurately a pipeline of transformations on a single set of data. You can’t post additional items to a cold Flow from outside of the Flow, and since the image-loading jobs come from the UI posting to the background and the images are revealed, that rules out the possibility of a cold Flow. And a hot channels/flow is not necessarily good or bad, you just need to know how to properly manage it. It’s like a blocking queue, where items get inserted in one end from anywhere, and consumed sequentially in-order from the other end. This is a better choice for handling events that come from the UI, but it has the drwback that things are processed one-at-a-time, which would make the overall image-loading slower. A better option than either of those is just to launch the image-loading job directly from each image in the grid and load all images fully in parallel. There’s really no reason why you should wait for one image to finish loading before starting the next, so don’t limit yourself to a Flow because it seems like a higher-level API on suspending functions. Suspending functions are already a high-level API and should be the first place to start. Channels, Flows, and other coroutine types exist to solve a very specific problem, and are not designed to be general, higher-level mechanisms like one might be used to with RxJava.

Thank you. I understand that now better. I achieved what I wanted by defining a single thread coroutine just for the file-reading part. Everything before and after runs in parallel.

If it's an IO operation (like loading a file), it's probably better to load them all in parallel (if it's IO-bound anyway, the OS will make it sequential, and if it isn't you get a bit more speed). I'm interested in what your architecture looks like. For example, using React, the easiest solution would be to have a useEffect in your component that launches to load that particular imagine, and let other components deal with their own things. It's unlikely you use React though so I'm curious what your implementation looks like so we can help better

I use Jetpack Compose for Desktop

Oh yeah, since you’re using Compose you really shouldn’t be bother with posting the image-loading to a background queue. That’s just making things more complicated than it needs to be, and what would be more useful is only loading the images that are actually visible on the screen. Using

produceState

with

LazyVerticalGrid

to load the image for each view will keep things declarative, but also cancel loading when the view leaves the screen if it hasn’t finished yet (so you’re not wasting system resources loading images that won’t be seen). Also to that point, if the screen feels sluggish and that’s why you’re looking into this, it might be due to the lazy grid (not the image-loading); there seem to be a lot of performance issues with that right now. Image-loading should all be happening in a background thread and would not cause UI jank or low framerates; at worst, unoptimized image-loading would just make it take slightly longer for the image to become visible, but should not impact the responsiveness of the UI itself

How can I cancel if its leaving the stream? I only find the DisposedEffect which triggers later.

There are lots of types of effects in Compose for various purposes. This doc page does a good job of describing them all; some launch coroutines, some return values, but all are tied to the Composable’s lifecycle, which is what’s most important. For example,

LaunchedEffect

isn’t the only way to launch a coroutine;

LaunchedEffect

is more of a “fire-and-forget” coroutine, but you also have

produceState

which launches a coroutine and returns a result as a

State

. You can also

rememberCoroutineScope

to get a handle to a

CoroutineScope

and do more custom stuff with it, if needed. To your example, you should be using

produceState

instead of

LaunchedEffect

(and you should’t need to do an additional

launch { }

inside

LaunchedEffect

either, it’s already running a coroutine). https://developer.android.com/jetpack/compose/side-effects#producestate If your image-loader already exposes a

suspend

API, then it should clean itself up automatically when it gets cancelled. If it’s a callback-based API, you can clean that up with coroutines APIs when the coroutine is cancelled. It’s the job of Compose to decide when to cancel the coroutine, and the coroutine’s job to unsubscribe and/or cancel the background work in response to cancellation. This snippet shows how one might tie a callback API to coroutines and cancel it properly (example uses OkHttp), entirely within the normal coroutines library: https://github.com/gildor/kotlin-coroutines-okhttp/blob/master/src/main/kotlin/ru/gildor/coroutines/okhttp/CallAwait.kt#L36-L56 Or,

produceState

includes its own

awaitDispose

function for the same purpose: https://developer.android.com/reference/kotlin/androidx/compose/runtime/ProduceStateScope#awaitDispose(kotlin.Function0) And here’s how you could transform your snippet to using `produceState`:

kotlin
@Composable
fun AsyncImage(
    photo: Photo,
    imageLoader: ImageLoader
) {
    val imageBitmap = produceState<ImageBitmap?>(initialValue = null, photo) { 
        value = withContext(Dispatchers.Default) {
            imageBitmap.value = imageLoader.loadThumbnailImage(photo)
        } 
    }

    imageBitmap.value?.let {
        Image(
            it,
            null,
            modifier = Modifier.padding(8.dp)
        )
    } ?: run {
        Placeholder(100.dp)
    }
}

Thank you. That helps me a lot to make it a cleaner solution. 👍

I’ve only used Compose on Desktop so I don’t really now how it compares to Android, but I think it’s just a general problem with lazy lists right now, where they perform worse than non-lazy lists, and isn’t related to images or any specific content in the list. And yes, the view getting reloaded is exactly the behavior I was thinking of, I don’t think

produceState

gets cancelled when something is non-visible (like scrolling off-screen), it’s cancelled because the view gets disposed when its scrolled off-screen in a lazy list

Thanks. I will try that out. I just discovered that part of the problem might be that you can't directly draw an Image but you need to wrap it into a ImageBitmap which has a IMHO expensive readPixels() method if it creates a new int/byte array on every image drawing.