It would be intriguing to have a library or compon...

# compose-desktop

[Stefan Oltmann]

It would be intriguing to have a library or component that progressively loads a progressive JPEG into an Image composable and is cancellable. 🤔

I'm not certain if something like this currently exists for Compose Multiplatform. Moreover, I'm unsure if SKIA has the capability to handle progressive JPEGs or if it allows the saving of JPEG thumbnails progressively.

I am exploring ways to enhance the speed of my photo app further. One approach is to incorporate multiple thumbnail sizes, loading a very small one initially and a larger one subsequently (if the user hasn't scrolled away). However, what would truly be beneficial is the ability to stream a progressive JPEG into an Image composable and cancel it if no longer necessary. 🤔

This way, even if the user scrolls rapidly, they would always see at least a small portion (instead of my placeholder), and when they stop, the thumbnails would progressively become sharper.

At present, I find the performance of Ashampoo Photos to be somewhat unsatisfactory.

Did someone solve this problem? I’m aware of coil and Picasso, but I don’t see that they have such a mechanism.

[kenkyee]

landcapist with Fresco?
https://github.com/skydoves/landscapist
But it won't be multiplatform...

[MR3Y]

Are you aware of https://github.com/saket/telephoto ? This should address half of the problem by subsampling images in memory not sure about the cancellation part though.
The author wrote a blog post about it https://saket.me/compose-sub-sampling-image-viewer/ as well if you're interested.

[Stefan Oltmann]

@MR3Y Thanks for the hint. If Telephoto had a implementation for iOS I could improve the performance of my hero view. 👀

The subsampling technologies used behind that seem indeed to be the next best thing to progressive JPEG. Progressive JPEG would still be better, because even a subsampled Bitmap must be read as a whole (with some bytes in between skipped) which will take more time.

It’s a possible next step. 🙂

[Stefan Oltmann]

@kenkyee You are referring to the ThumbnailPlugin and specifically Fresco because of it's progressive JPEG capabilities.

Yes, I'm indeed asking for a Multiplatform solution of that. 🙂

Fresco seems only to be available for Android unfortunately. 😕
It's requested for Coil (https://github.com/coil-kt/coil/issues/940).
And denied for Glide (https://github.com/bumptech/glide/issues/1042).
Reading through the discussions it looks like SKIA won't get that feature.

[Stefan Oltmann]

@Colin White As you plan to bring Coil to Multiplatform, do you have any idea if progressive JPEGs will be possible?

I understand that for Android there is native support. What about JVM & iOS?

[Stefan Oltmann]

And of course I would need a multiplatform JPEG encoder.
Right now I do everything just using skiko, but SKIA has no planned progressive JPEG encoding support.

[kenkyee]

could wrapper a different image decoder for each platform w/ KMP too? Is there an iOS native one that supports it?

[Stefan Oltmann]

Indeed, if every platform has a way to do that I could use expect/actual for that instead of skiko.

Java ImageIO seems to have an progressive encoding option.
Apple Core Image has kCGImagePropertyJPEGProgressive

[Stefan Oltmann]

Uh... there jxl-coder-swift ... I forgot about JPEG XL. If it supports progressive encoding/decoding.

My thumbnails don't have to be JPEGs. I could use whatever performs the best. 👀 The goal is just to show the thumbnails in the gallery as fast as possible while users are scrolling through it.

[kenkyee]

also this for webp: https://github.com/SDWebImage/SDWebImageWebPCoder

[Stefan Oltmann]

For the progressive decoding part I hope someone creates a library to easily integrate external libraries with Skiko for image display. While there's some interoperability with SKBitmap, the process seems complex and requires substantial effort.

Resizing and encoding could be done completely in the actual implementation.

[Colin White]

Android supports decoding progressive JPEGs, but it isn’t true progressive JPEG support as it waits for the final image then returns that. It’s not possible to emit sampled images as it decodes the progressive JPEG’s data. Coil and Glide already support that just by using BitmapFactory to decode images

[Colin White]

I think that Skia has the same level of support (only outputting the final image) though I haven’t verified that. If that’s the case then it should already be supported via the latest Coil 3.0 alphas, which support multiplatform

[Colin White]

For supporting emitting sampled images during the decode process, I don’t think it’ll be supported. We’d need support from a native decoder on both Android and non-Android platforms. Also Coil’s decode pipeline is built to read an image source then emit only one image. Changing that behaviour would add a lot of complexity in Coil’s public API as well as internally, which I’d want to avoid

[saket]

yeah android's image decoder really does not like progressive jpegs

[saket]

telephoto used to initially decode images in parallel on multiple threads to speed up things, but i ended up undo-ing this behavior as the decoders start choking if they're given a progressive jpeg.

[Stefan Oltmann]

Interesting. 🤔

Hopefully we get one day a KMP JPEG XL encoder/decoder with support for progressive JXL and a SKBitmap compatibility layer. I assume that’s what I ultimately want to have.

Fresco is only available for Android and as far as my research goes there are reasons to not use Fresco in general.

So I will go with creating two sizes of thumbnails - one very very small to instantly show to avoid showing whitespace and another one after loading. On some platforms I may read the smaller thumbnail from the same file using a different sample size, like Saket described in his blog post.

The next thing is waiting on telephoto to have iOS support to improve my hero/full image view.