Question: how does it work?

[AndroidDeveloperLB]

Does it do downsampling again and again on the same file, or does it load all into JNI, and then just pick the pixels it needs ?

Or maybe it has the option to choose from them ? I mean, it would be a waste to downsample all the time, when you can have it all in the RAM (without being afraid of OOM) ...

[Piasy]

That's implementation detail of SSIV, briefly speaking:

It does a downsampling when load the image fully into screen (as a Bitmap, so it's in java heap), that downsampling is optional too, if the image is very small, no downsampling happens, then when user zoom the image, only several regions of the image is decoded (also as Bitmap, java heap).

For more detail, you can refer to https://github.com/davemorrissey/subsampling-scale-image-view .

[AndroidDeveloperLB]

I see. Can you also add the JNI solution?
I think it should be better in terms of performance and maybe even heap memory usage.
You could even downsample in your own way. As I remember, the downsampling of Android is only of power of 2, and it sometimes has some aliasing in it.

In the past, I created a library that shows how to mess around with bitmaps, but sadly it doesn't do the decoding in JNI: https://github.com/AndroidDeveloperLB/AndroidJniBitmapOperations
However, I remember I saw a library that does the decoding in JNI too, yet it wasn't seem to be easy to use.

[Piasy]

Image loading and cacheing, that's the responsibility of image loading library, e.g. Fresco, Glide, Picasso, and image displaying, including downsampling, pan and zoom, animation, etc, is the responsibility of image displaying library, e.g. SSIV.

This library focus on bridging them together, although currently only image loading library is configurable, but if there are other brilliant image displaying libraries, make it configurable is very easy.

[AndroidDeveloperLB]

I'm not complaining. I just suggest this as another option, because I think a single decoding (even if it's a bit long) might be better than multiple ones, as long as your device has enough RAM.
If you take, for example, a 40MP image, it takes around 40*4 = 160MB of RAM. This is a lot for heap memory, but it's fine for RAM itself, because most devices out there have at least 1GB of RAM.

[Piasy]

Yep, I understand. But I really think that's another image displaying library. Besides, I don't have enough knowledge and time to do such thing, currently.

If you have a good solution, I can modify this library to use your image viewer as an option :)

[AndroidDeveloperLB]

Sadly the more I read about it, the more complex I saw of how to decode images in JNI.

[Piasy]

I'm going to close this issue, if you have other questions, please feel free to reopen it :)