I think such a transformation would go against the resource sensitive nature of Glide.

.centerCrop() and .fitCenter() are loading the source image at a specified size of the target (usually an ImageView) downsampling and/or cropping to that size. If you think about what would .centerInside() do as a Transformation you will quickly see that it would need to create a bigger transparent image and draw the smaller Bitmap inside, or in other words pad the small image with transparent borders to fit in the view. This is a waste of memory.

However you CAN load images as centerInside in a traditional sense:

• know that the image you're loading is smaller than the view
  larger images may be loaded by .asBitmap().atMost() if I remember correctly so they're downsampled just like with fitCenter.
• set android:scaleType="centerInside"
• add .dontTransform() to your load line
• make sure you don't call .centerCrop() or .fitCenter(); or make sure you call them before .dontTransform(). The last call wins.

Let me know what you think about the above, I may be wrong.

I think you misunderstood what I said centerInside().

centerInside not need to create transparent image.

for example

I have a image, the size is 100x100px.
I also have a ImageView size set 300x300px.
now I use glide to load this image show on the imageView,
apparently glide will zoom in the image to 300x300px.

I think sometimes it don's necessary. because it would need more memory, and any scenes would not need zoom in the image.

my mean about centerInside()，you can see the picasso's method centerInside().

thanks for you reply!

Heh, that's right fitCenter could waste memory as well for small images and big views :)

Try the step by step I wrote.

Sorry! I don't understand Try the step by step I wrote. meaning.

Follow the bullet points at "you CAN load images as centerInside", the most important ones are 2nd and 3rd.

Thanks for your suggestion.
But some scenarios may not need zoom in images.
like image viewer:
I want to show any image, and the imageView's width and height is match_parent.
(if image size larger then imageView size, use like fitCenter, else keep the image original size)

In this time, glide can't do this. it will fit imageView.

I holp you can reconsider my suggestion. thanks again!

Glide can't do this. it will fit imageView.

dontTransform turns this automatic fitting off and lets the image view display the image as is.

if image size larger then imageView size, use like fitCenter, else keep the image original size

This is the definition of centerInside you set on the ImageView in the XML.

I'll check this later, there may be missing piece if it doesn't work when you tried it.

You can run a picasso demo, it hava centerInside() method, sometimes useful.

Looking over this again, I think fitCenter() and centerInside() are identical?

The ScaleType definition of CENTER_INSIDE is:

Scale the image uniformly (maintain the image's aspect ratio) so that both dimensions (width and height) of the image will be equal to or less than the corresponding dimension of the view (minus padding).

The ScaleType definition of FIT_CENTER redirect's to Matrix.CENTER:

Compute a scale that will maintain the original src aspect ratio, but will also ensure that src fits entirely inside dst. At least one axis (X or Y) will fit exactly. The result is centered inside dst.

Yes!
So, we also need centerInside(), but glide didn't have. it is useful sometimes, include less memory.

@sjudd no, it's not the same. The big differnce comes when you have a drawable that's smaller the the ImageView dimensions. fitCenter will explode it and make it blurry, while centerInside will display it with transparent padding, original size. Compare "will be equal to or less than" and "ensure that src fits entirely inside".

Lookey here: http://bon-app-etit.blogspot.hu/2014/01/imageview-scaletypes.html It's sad that this is the 5th article Google gave me and all the others fail to demonstrate any difference between most of the scaleTypes.

Ahh I see what you're saying, thanks for the clarification. Makes sense, we should add centerInside(). A pull request here would be welcome, it's probably very similar to fitCenter().

Ah so to do any of the other fitStart and others it all needs to be done via a new Transformation and a new method on builder and changing the switch in into()?

Yes I think so. It may not need an actually new Transformation class, it may be possible to add parameters to constructors, but it should probably have a new method on the builder.