bumptech / glide

An image loading and caching library for Android focused on smooth scrolling
https://bumptech.github.io/glide/
Other
34.62k stars 6.12k forks source link

why scale bitmap larger than original picture?there is waste too mush native memory #4483

Open zengjingfang opened 3 years ago

zengjingfang commented 3 years ago

ForMy Test: exactScaleFactor will >1 when original picture < view ,then the bitmap size will be larger than original picture, there is waste too mush native memory. why ?

For example: My picture is 750x1733,but bitmap decode is 1176x2091,transform centerCrop will be 1080x2091。 At last: there is create two bitmap, and all larger than picture。 My device screen: 1080 x 2091

<ImageView
        android:id="@+id/glide_image_test"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:scaleType="centerCrop"
        />

Glide.with(MainActivity.this).load("xxx").into(imageView);

DownsampleStrategy imageView scaleType case1:original picture > View , original picture750x1733, view180x300 case2:View > original ,picture original picture 750x1733, view1080x2091.
AtLeast 0.25 1.0
AtMost 0.125 1.0
FitCenter 默认,fitStart,fitEnd,fitCenter 0.22505626 1.44
CenterInside fitXY,centerInside 0.22505626 1.0
CenterOntside center,centerCrop 0.24 1.5686421
None 1.0 1.0
sjudd commented 3 years ago

centerCrop means you want the image to fill the view. You can override that with one of the other transformations as you've noted.

By default we upscale images so that we can maximize bitmap pool hit rates (we hope). That's kind of legacy behavior at this point, but it's hard to change the default without breaking a bunch of apps.

zengjingfang commented 3 years ago

@sjudd the "bitmap pool hit rates" you say is "LruBitmapPool" ? If it is, i don't think so . On our application business , if the picture is small than view ,it is aways full screen background or very big view. On this case, We should focus on memory allocated more。

If we decode by picture size, it does not influence the bitmap pool "hit rates",because next picture will be same size also.

And on the other hand, for my test ,cpu will be lower when decodeBitmap for smaller size.

As your say, there is kind of legacy behavior ,and you can not change it just consider the impact on other apps?

I changed it on my app(exactScaleFactor <=1 ), and it better or worse for my business on your opinion?

tennkou commented 2 years ago

according to the annotation of BitmapFactory.inScaled, "the bitmap will be scaled to match inTargetDensity when loaded, rather than relying on the graphics system scaling it each time it is drawn to a Canvas." , maybe this is also a reason. But i also don't think it is worse to waste memory.