Local Uris are always queried twice

[TWiStErRob]

Glide Version/Integration library (if any): 3.6.0-SNAPSHOT
Device/Android Version: S4/4.4
Issue details/Repro steps: ImageVideoModelLoader acquires both InputStream and ParcelFileDescriptor for almost everything:

• load(R.raw.svg):
  android.resource://net.twisterrob.app/raw/svg
• load(ContentUris.withAppendedId(ITEM_URI, id).toString()):
  content://net.twisterrob.app/item/1579
• load(new File(new File(context.getFilesDir(), "images"), "item.jpg").toString()):
  file:///data/data/net.twisterrob.app/files/images/item.jpg

The realization that this happens came when I was profiling an activity startup and saw that there are two 800ms database accesses happening in the background. The 800ms was my bad (missing DB indices), but at least it was clearly visible:

I'm transitioning to a ContentProvider to give access to the images with openFile, so the above image displays how content://net.twisterrob.app/item/1579 looks like when handed to Glide. I was able to reduce the time required to query the PFD/IS but some may not be that lucky (web backend). Doubling the load time seems unnecessary and as you can see the image could have been already read if just queried once.
The case with R.raw.svg is even worse since the IS is already ready and trying to fetch a PFD fails all the time, because of a limitation on raw resources (only aapt uncompressed one can give a PFD).

Why is it needed to acquire the ParcelFileDescriptor when you already have an InputStream?
Is there an easy way to avoid going through ImageVideoModelLoader?
Is there a way for to always use only one or the other? (I guess with some .decoder magic).

[sjudd]

I think its due to exception handling, but I can't totally remember. This is definitely fixed in Glide 4.

Unfortunately I'm not sure there's a super simple way to work around this.

The initial theory was that opening the PFD wasn't a particularly expensive thing to do since content with PFDs would be local anyway and the cost was only incurred once (before the image was cached). Not a great excuse though.

[TWiStErRob]

Glad it's fixed in v4.

Assuming that it doesn't take time is not a nice thing to do. I'm doing a DB request which returns a BLOB in a Cursor which then I feed into a ParcelFileDescriptor.createPipe() on a background thread to avoid saving a file. Please note that I have the byte array here in memory (from DB on disk), but with the same method I could query an Internet stream and copy that into the pipe.

Luckily I found a simple enough way after some digging which seems to work. I replaced:

.fromString()

with

.using((StreamModelLoader<String>)Glide.buildModelLoader(String.class, InputStream.class, context))
.from(String.class)

The only thing I don't like is the cast, but if I don't cast, I lose the DrawableTypeRequest and some .as() magic is required too.

[TWiStErRob]

I close this since it will be (already) fixed in v4 and you most likely won't touch v3 related to this. Also there's a good enough workaround for v3.

[TWiStErRob]

It also looks like a duplicate of #77.