-
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
Canvas: trying to draw too large bitmap. #3775
Comments
+1 |
If you're able to reproduce it in a test or a sample app let me know. Other than changing the inputs to the logic in Downsampler I'm not sure that disabling the disk cache should matter. How large is the actual view? |
@sjudd Thanks for the answer. I'm able to reproduce it with our app. And definitely happens only when we have the disk cache enabled. As soon as I disabled it, goes smooth. I will try to make a sample app where you can also reproduce it, and will try upload also a video in the course of the following days. Will also give you more info about the view and the dimensions of the image itself when uploading the video as well. |
@sjudd Here I have a sample app that crashes with my case: https://github.com/franvis/glide-crash-sample |
@franvis yes i have test your code and then crash on Pixel 3XL emulator. |
@sjudd hello ~ How to fix this issue ??? |
This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions. |
@sjudd Hello!! Can you tell us a bit more about this? |
Unfortunately I'm not able to reproduce the issue with the sample app. I don't see any difference in image sizes decoded with or without disk caching enabled. My recollection is also that |
@sjudd Pixel 3XL emulator will be crash . i have test when you swipe image to the last item. |
This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions. |
@sjudd Hello! I'm still able to reproduce it with the sample app, by simply swiping it just crashes. Here you have a stacktrace of it: |
This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions. |
@sjudd Any news again? |
nothing ? |
I faced with this case too. When the image is narrow, in onResourceReady callback we can see, that resource have too large width and height. So possible solution its just use .override(screenWidth) |
This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions. |
@shpasha But. i need show origin image ~ ~ ~ |
How to fix this issue ? |
Ok on a Pixel 3XL I was able to reproduce, here's the Downsampler logs:
|
Ah ok the disk cache strategy is red herring, it just makes it more likely that you'll have a race condition where the thumbnail request finishes more quickly than the non-thumbnail request. You can reproduce the crash with any disk cache strategy, it's just more likely with one than the other. The actual issue is:
The simplest fix is to either use a more proportional image, or to explicitly set a more reasonable downsample strategy (FIT_CENTER, or even CENTER_INSIDE). There's some argument to be made that the thumbnails should also use the transformation based on the ImageView's scale type, but we've never done so in the past and it might be a subtle breaking change to start doing so now. I'll leave this open to consider making the thumbnail inherit the ImageView's transformation as well if a transformation isn't otherwise specified. #2964 already discusses avoiding upscaling by default. Here's the Downsampler logs using FIT_CENTER:
|
Actually I'm going to file a new issue for the transformation on thumbnails, will close this as otherwise broken as expected. |
I am using the default CENTER_OUTSIDE strategy and I still want to use it because of design reasons. Alternatively, can we add a reasonable limit for the DownSampler? Because loading a 39059 px tall bitmap just doesn't make sense and will certainly fail anyway. |
You could avoid CENTER_OUTSIDE, use a non-scaling strategy, and upscale in the view itself? Or you can write your own DownsampleStrategy to meet whatever your requirements are. It's going to be hard to define a reasonable safe limit that applies to all loads in all applications. |
Hello @sjudd! I tried your possible solutions and changing the downsample strategy to centerInside() like
Still gives me a crash in the sample app I shared with you and we are having quite a lot of crashes in our production app as well... Any other suggestion or possible solution? |
@sjudd Moving to |
|
Do not use |
@Hamza417 what if we need that? In my case I don't have height-width coming from api only image url and i have like image -text- gif 3 view types so i have to use |
Hello, in my case I have solved that by doing the following:
|
hi @franvis , summary to solve this problem is implement like this, right?
btw, i couldn't access this link https://github.com/franvis/glide-crash-sample, error 404 |
I can reproduce the same crash with the following parameters.
|
I use xamarin, I had to scale down images. Its the height and width of the images are the problem to Canvas |
Glide Version: 4.9.0
Device/Android Version: Fails in several Samsung devices (95%) and a few of other brands (5%) (I managed to reproduce it in a Samsung Galaxy S8 and in a Google Pixel C tablet)
Issue details / Repro steps / Use case background:
We are currently having several crashes with
This happens when loading images in AppCompatImageViews that are in a ViewPager. We managed to solve this disabling disk cache by adding
.apply(RequestOptions().diskCacheStrategy(DiskCacheStrategy.NONE))
Glide load line /
GlideModule
(if any) / list Adapter code (if any):Why do we have to disable disk cache to prevent this crash? Is there another way of fixing this crash in our case?
Thanks!
The text was updated successfully, but these errors were encountered: