-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why not have centerInside()? #591
Comments
I think such a transformation would go against the resource sensitive nature of Glide.
However you CAN load images as
Let me know what you think about the above, I may be wrong. |
I think you misunderstood what I said centerInside not need to create transparent image. for example I have a image, the size is 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 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 |
Follow the bullet points at "you CAN load images as centerInside", the most important ones are 2nd and 3rd. |
Thanks for your suggestion. In this time, glide can't do this. it will fit imageView. I holp you can reconsider my suggestion. thanks again! |
dontTransform turns this automatic fitting off and lets the image view display the image as is.
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
The ScaleType definition of
|
Yes! |
@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. |
Note: using dontTransform() along with android:scaleType="centerInside" does not seem to make any difference. Switching from Picasso to Glide results in a different size when loading a 64x64 PNG image into an ImageView with height 150dp and width match_parent -- in Glide the image is much smaller than using Picasso or setImageResource() directly. Adding dontTransform() to the load line had no visible effect on the size at all in 3.7.0. |
@LorneLaliberte There may be some DPI in play there, try to load with each of those and then check the Bitmap size or Drawable intrinsic size for clues. ...or take a screenshot and do some measurements :) You can also try playing around with |
Hmmm...I don't understand how there could be any DPI differences with the same resource in the same target ImageView on the same device. The difference in visible size is quite dramatic (it's about 1/4 what it should be). Using asBitmap().asIs() and asBitmap().asIs().dontTransform() made no difference either, the image in Glide is tiny compared to loading the exact same image with Picasso or setImageResource(). |
Hmm, I assumed (based on setImageResource) that you're loading from |
In this particular case it's in However it shouldn't matter where it is being loaded from if it's loading from the same place in both tests. Using Picasso the size matches Edit: or somehow avoiding the standard resource transformations and not applying an equivalent transform. |
Check the I was curious and checked and indeed Picasso calls Based on this if you create all the scaled versions correctly you should end up with the same results with all three types of loading. Alternatively you're free to replace this default loading style inside Glide with one that loads the Drawable as is through Resources or BitmapFactory. |
I'm actually using an So to make Glide match the standard behaviour for density-specific resources I would need to apply a custom transformation based on the device density. Which isn't really worth it; might as well just use It probably doesn't make a lot of sense to load density-specific resources if you're going to transform them further anyway; you'd be better off putting them in drawable-nodpi etc.. In my case this was just a test where an existing resource was used for convenience, and the difference in scaling behaviour was unexpected because I assumed Glide would also take the density into account for compatibility reasons. |
Glide transforms the I don't see any reason (curious: what is yours?) why you would want to load them this way (other than maybe a custom transformation applied), the Resources already has built-in caches for Drawables, and Glide doesn't support XML Drawables yet anyway (#350). I'm not sure what's the history behind this type of loading (ignoring density), @sjudd may shed some light on it, but likely it wasn't worth it (why duplicate ... thinking a little more, actually it may be possible to use a transformation/custom target that doesn't create a new Bitmap just sets the density to the correct value, if it can be set post-creation. |
In this specific case I was using an existing resource in my test purely for convenience (it was already there). The original motive is to use a common data binding attribute for images that might be remote or might be a resource, and applying custom transformations, so basically just to simplify the binding adapter implementation. (In our case drawable resources are supplied by a third party, although in production they would be processed for sanity checks first.) The same can be done with multiple attributes, but I was exploring using a common attribute (hence the resource in URI form). If I was starting from scratch I may not have noticed any difference in behaviour, but since I was testing by modifying an existing project the difference between Picasso and Glide was immediately obvious.
Ah, that's very good to know.
|
You would've found it out eventually ;)
Yep, I remembered something like this, the questions is: Is this the only difference between a Glide and Picasso/setImageResource loaded Bitmap/BitmapDrawable or there's more to it? |
I think I figured out why |
This would be really helpful. fit().centerInside() or fit().centerCrop() is an important feature |
@TWiStErRob I switched to 4.0 snapshot. For some reason, I get a compile error - "placeholder cannot resolve method 'placeholder(int)' |
@rpn2142 Major version change means breaking changes... check the |
@TWiStErRob Thanks. got it working. |
Sometimes we need to load image for center inside, but I have not found this method!
Can add method for center inside?
The text was updated successfully, but these errors were encountered: