Progressive Support

[Mine181]

I want to confirm if Progressive support is available, as images exported from Image Toolbox aren't progressive.

[awxkee]

I can confirm it is not available and this is something that I definitely won’t do.
I can accept PR only for this, and based on code I’ll decide if it is worthy to maintain this or not.
Just from my point it will likely add some complexity, and will add negative value for this, because actually it is almost no where supported and will drain some resources to maintain it.

[Moheeeetgupta]

I am planning to add support for progressive jxl so that we can load images progressively on android apps.
Wanted to understand why do you think this will add negative value for this?
Even if it is not supported anywhere, it can be decoded progressivly on android apps with this plugin and added functionlity right ?

[awxkee]

Glide and Coil do not support progressive loading. From browsers jxl is supported only for Safari, might be some browsers with tiny market share support this, but this gives no value.
Therefore, this feature is not supported by the library's main audience, and there is almost no support outside it either. In short the feature is supported almost nowhere yet it would still require ongoing maintenance.
Even if by a chance Chrome adds support for JXL this is not typical behavior when someone will encode images by this library to export them to a web resource.

[Moheeeetgupta]

I understand that Glide supports One fetch → One decode → One result architechture.
The architechture seems entirely incompatible to progressive rendering.
To support progressive loading, it will require major rewrite in:

1. DecodeJob state machine
2. EngineJob completion logic
3. Target to accept multiple updates
4. Cache layer (how to cache partial images?)
5. Transformation pipeline (when to apply?)

As far as I understood, libjxl exposes progressive/incremental decoder with event name: JXL_DEC_FRAME_PROGRESSION.
When JXL_DEC_FRAME_PROGRESSION fires, the pixel buffer contains a partial/lower quality version of the image that gets progressively refined. We can extract these intermediate buffers and expose them as Android Bitmaps.

do you have any suggestions around adding support for progressive rendering in glide?

The reason I think this should be implemented even though it is not supported by many browsers and OS is because there are quite good volume of android users who are on bad network conditions and if we could enable glide to support progressive loading then time of seeing the loader/shimmer will reduce significantly as time to first paint is quite less for progressive jxl.

[awxkee]

To support progressive loading, it will require major rewrite in:

DecodeJob state machine
EngineJob completion logic
Target to accept multiple updates
Cache layer (how to cache partial images?)
Transformation pipeline (when to apply?)

This is missing problem that one-shot loading doesn't have, it's load balancing. You need to determine by some heuristic, analysis, and experience, how often data can be sent to the progressive decoder to maintain reasonable performance and acceptable battery usage. For each additional image loading simultaneously, this task becomes more and more complex.

As far as I understood, libjxl exposes progressive/incremental decoder with event name: JXL_DEC_FRAME_PROGRESSION.
When JXL_DEC_FRAME_PROGRESSION fires, the pixel buffer contains a partial/lower quality version of the image that gets progressively refined. We can extract these intermediate buffers and expose them as Android Bitmaps.

From library's implementation side this is reasonably straighforward. You send next chunk to the decoder and if amount of data is enough to decode frame it will give you the next frame.

The reason I think this should be implemented even though it is not supported by many browsers and OS is because there are quite good volume of android users who are on bad network conditions and if we could enable glide to support progressive loading then time of seeing the loader/shimmer will reduce significantly as time to first paint is quite less for progressive jxl.

It was not added for a reason. Majority of android devices lacks of hardware JPEG/PNG decoder and those devices simply to slow to perform progressive rendering with software decoding. This is not the best way to utilize battery also. Progressive rendering on PC was invented due to combination of factors that connection speed was low and amount of energy that you can spend on decoding and rendering doesn't matter.

do you have any suggestions around adding support for progressive rendering in glide?

No, I'm not familiar with Glide internals.