I was wondering whether Jetpack Compose encourages...

# compose-android

[Mohammed Hashim]

I was wondering whether Jetpack Compose encourages using multiple pixel-density assets for this use case.
I’m trying to render a WebP background image across the full layout, and it got me thinking about whether Compose/Android still recommends providing density-specific versions (mdpi, hdpi, xhdpi, xxhdpi, etc.) for raster assets.
For example, I currently have a single WebP in res/drawable/ and render it like this:

Box(
    modifier = Modifier
        .fillMaxSize()
        .paint(
            painter = painterResource(R.drawable.my_background_image),
            contentScale = ContentScale.FillBounds
        ),
    contentAlignment = Alignment.Center
) {
    Text(
        text = "Hello over background!",
        color = Color.White,
        fontSize = 24.sp
    )
}

I’m not seeing any noticeable performance issues on the devices I have available.

So my question is: for a full-layout background image like this, is there any performance or rendering benefit to providing density-specific WebP assets on Compose Image?
Would appreciate any insights from people who have dealt with this in production.

[romainguy]

On Android, if you don't provide density-specific assets, whatever you end up loading will be scaled at load time. This means loading the app will be longer and use more memory (~ish).

[romainguy]

It can also affect quality if the device's dpi is way lower than the loaded asset. Android will only use a simple bilinear filter, which may or may not look great (too blurry/loss of details in some cases).

[romainguy]

So it's really up to you. But today you shouldn't provide assets for all densities. Not sure which ones make sense today, but x(x)hdpi and xx(x)hdpi is probably enough if you are targeting phones/tablets.

[romainguy]

BTW you should NOT put your WebP in drawable/. That's the equivalent of -mdpi which means the asset will be scaled up on high density display. You don't want that because it won't look good (upscaling has to make up information), or it will make your asset use way too much memory

[romainguy]

drawable-anydpi/ makes more sense if you don't want the asset to be resized, otherwhise put it in whatever dpi buckets that matches the actual density of the asset.

[Mohammed Hashim]

Thanks for the reply @romainguy.

[Mohammed Hashim]

following up on this,

[Mohammed Hashim]

Google now requires developers to build apps that support runtime resizing, split-screen, and landscape orientations. This brings up to the question of supporting different form factors, such as phones, foldables, and tablets.

[Mohammed Hashim]

Given that, should we also consider providing raster assets in size-qualified resource directories such as drawable-sw600dp/, drawable-sw720dp/, etc.?

[romainguy]

That depends on what you use the assets for but that seems unnecessary. In general only the density will matter

[Mohammed Hashim]

Gotcha 👍