SOURCE and RESULT cache read by same cacheDecoder

[TWiStErRob]

Glide Version/Integration library (if any): 3.6.1
Device/Android Version: above API 10, so almost any
Issue details/Repro steps/Use case background:
I was playing around to try my proposed solution for #700 (sample code in that issue) and found this issue. The idea there is to SOURCE cache the original image file and use BitmapRegionDecoder read parts of the image. The problem is that when I specify cacheDecoder it not only reads from SOURCE but from RESULT cache as well. When it tries to load the specified rect from a smaller image it throws a "rectangle is outside the image" correctly. There is no way to work around this because I can't tell which cache contains the File I received to decode.

Glide load line:

Glide
        .with(context)
        .load(url)
        .asBitmap()
        .override(viewWidth, viewHeight)
        .decoder(new RegionImageVideoDecoder(context, rect))
        .cacheDecoder(new RegionFileDecoder(context, rect))
        .diskCacheStrategy(DiskCacheStrategy.SOURCE)
        .into(holder.imageView)
;

Stack trace / LogCat:

java.lang.IllegalArgumentException: rectangle is outside the image
    at android.graphics.BitmapRegionDecoder.decodeRegion(BitmapRegionDecoder.java:371)
    at net.twisterrob.app.glide.github._700_large_image.RegionResourceDecoder.decode(RegionResourceDecoder.java:29)
    at com.bumptech.glide.load.engine.DecodeJob.loadFromCache(DecodeJob.java:222)
    at com.bumptech.glide.load.engine.DecodeJob.decodeResultFromCache(DecodeJob.java:85)
    at com.bumptech.glide.load.engine.EngineRunnable.decodeFromCache(EngineRunnable.java:108)
    at com.bumptech.glide.load.engine.EngineRunnable.decode(EngineRunnable.java:99)
    at com.bumptech.glide.load.engine.EngineRunnable.run(EngineRunnable.java:58)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
    at java.util.concurrent.FutureTask.run(FutureTask.java:237)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
    at java.lang.Thread.run(Thread.java:841)
    at com.bumptech.glide.load.engine.executor.FifoPriorityThreadPoolExecutor$DefaultThreadFactory$1.run(FifoPriorityThreadPoolExecutor.java:118)

See also https://docs.google.com/drawings/d/1KyOJkNd5Dlm8_awZpftzW7KtqgNR6GURvuF6RfB210g/edit?usp=sharing

[TWiStErRob]

In the BitmapRegionDecoder's case it's not possible to work around this issue, because there's no way to tell which cache is being decoder, but in case of other custom formats (#718) it may be possible to work around by encoding RESULT cache with the same format as the SOURCE image, so the same decoder can read it.

Another possible workaround in case of a custom format may be is to check the magic in the beginning of the file:

if (isMyCustomFormat(source)) { // make sure to rewind the stream after reading the magic bytes
    return decodeMyFormat(source);
} else {
    return fallbackDecoder.decode(source, width, height); // `fallbackDecoder` is a `StreamBitmapDecoder`
}

an extensive live example can be found of this approach in TWiStErRob/glide-support@01e63ab

[sjudd]

This exact use case came up again internally. Internal bug is b/65126333

[TWiStErRob]

Is this still true in v4?