Issue 1:
Glide Version: 4.0.0-RC0

Integration libraries: okhttp-integration:4.0.0-RC0

Device/Android Version: Galaxy S6 SDK version 25

Issue details / Repro steps / Use case background:

When using an annotation processor, generated class GlideRequests contains duplicate field:

@Override
public <ResourceType> GlideRequest<ResourceType> as(Class<ResourceType> resourceClass) {
return new GlideRequest<>(glide, this, resourceClass);
}
@Override
public <ResourceType> GlideRequest<ResourceType> as(Class<ResourceType> resourceClass) {
return (GlideRequest<ResourceType>) super.as(resourceClass);
}

My module:

@GlideModule
public class GlideAppModule extends AppGlideModule {
@Override
public void applyOptions(Context context, GlideBuilder builder) {
builder.setDiskCache(new InternalCacheDiskCacheFactory(context, 20 * 1024 * 1024));
}

@Override
public boolean isManifestParsingEnabled() {
return false;
}
}

Extension:

@GlideExtension
public final class GlideAppExtension {
private GlideAppExtension() {}

@GlideOption
private static void cropCircle(RequestOptions options) {
// TODO
}
}

Should i use in build.gradle:

annotationProcessor 'com.github.bumptech.glide:compiler:4.0.0-RC0'

or

compile 'com.github.bumptech.glide:compiler:4.0.0-RC0

I've tried both, and tried SNAPSHOT version

Also in the documentation example the first argument is RequestOptions<?>, but the class from the sources is not generic?

Also in the code bellow, error drawable is not used when the url is null, and docs state: "null models will cause the error drawable to be displayed", this is working in the latest 3.x version.

Glide load line / GlideModule (if any) / list Adapter code (if any):

GlideApp.with(this).load(contractImage) // contractImage is null
.transform(new CropCircleTransformation())
.error(errorDrawable)
.into(imageView);

Issue 2:
We just started using Glide and I've been comparing the default RESULT disk cache strategy vs. SOURCE and I'm noticing that SOURCE is noticeably faster to render a newly net-retrieved image to the screen.

I'm playing with two second-gen Nexus 7's with Lollipop side-by-side with images ~200K, 700x700 average. I made the most minimal example I can and have ~100 images in a vanilla RecyclerView with a LinearLayoutManager where 4-5 images will be visible on screen at a time. If I start up both configurations from scratch and scroll to the very bottom of the view the SOURCE config finishes showing the images in less than a second whereas the RESULT config finishes showing them in 2-4 seconds. This is consistent with regular scrolling where images come down one at a time: SOURCE is always faster than RESULT.

Without diving in too deep into the code myself I'm suspecting that RESULT resizes the image before it shows it on screen. I'd imagine you could make it as fast as SOURCE if on the first/network retrieval you immediately show the full image in the view like SOURCE but on a background thread continue resizing the image and store it in the disk cache resized so on the second request it shows up resized.

And now that I've actually typed all that out I can see how that might be unexpected for someone not using something like fitCenter() where the difference between SOURCE and RESULT looks almost the same on screen...hmmm.

Does this use case sound interesting to you, though? I assume there're probably extension points where I could create the behavior I want using custom targets or something but I do really like how Glide handles all the view/adapter/recycling stuff behind the curtains for me.

Any suggestions for how to accomplish this with existing apis or if this is a valid enhancement request?

Thanks much!

Details:

RecyclerView.Adapter

@Override
public void onBindViewHolder(ViewHolder holder, int position) {
Glide.with(holder.itemView.getContext())
.load(thumbnails[position])
.fitCenter()
.crossFade()
// .diskCacheStrategy(DiskCacheStrategy.SOURCE)
.into(holder.image);
}

View Layout

<?xml version="1.0" encoding="utf-8"?>
<ImageView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="200dp"
android:scaleType="centerCrop"
android:background="#444444"
android:layout_marginBottom="10dp" />