Image skewing

[gbrbks]

Hey!

Your library is just awesome! I'd like to ask a help from you. I encountered on 4.1.2 devices that the images are teared apart at the center and skewed (see screenshots) but not everytime. Do you know what is the source of this problem? I tried it with various setup but still the same. I haven't encountered with it on other OS versions.

links:
https://www.dropbox.com/sh/1xjx7gafshyz13q/AACPDfSQo0Ja7c4KMIt2LbSWa?dl=0

Thanks in advance!

Cheers,
Gabor

[sjudd]

I'd guess it's related to bitmap re-use. I actually think I've seen this before, but I didn't think to note down the version of Android, thanks for doing that.

If you've forked Glide you can try forcing the BitmapPool to always return null when asked for Bitmaps and see if that fixes the problem.

[TWiStErRob]

Looking at the images the triangles formed on the lower right look like right angled isosceles (equal sided) triangles which means that the amount of skewing is equal to the height.

I had a similar problem a few days ago when manipulating int[] as a bitmap. When an image is skewed like this that means that the pixels from the 1D array were mapped with the wrong stride (the amount to skip between drawing lines, i.e. width probably in case of efficiency) so there must be some pixels missing, and there are. If you look at the bottom on the horizontal strip (the others have shadow which hides this), there are a few lines where you can see pixels from another image?

I'm not sure if it would be helpful, but if you can repoduce the issue consistently, it may worth swapping the pictures with distinct solid-colored ones to see where the other pixels are coming from (this would confirm Sam's re-using theorem).

@sjudd Without forking, would using BitmapPoolAdapter help? (run the following before first Glide.with):

Glide.setup(new GlideBuilder(context).setBitmapPool(new BitmapPoolAdapter()));

@sjudd I was looking around engine.bitmap_recycle.AttributeStrategy and LruBitmapPool, but nothing jumped out (I was suspecting threading, but both get and put are synchronized).

@hamutarto does it happen in the emulator as well, so it's easier to reproduce without having a target device? And also which Glide version is it? I'm not sure if it's trivial...

[gbrbks]

Thanks for the quick reply! I haven't tried with emulator just real devices (Note 8, Nexus S), but those can consistently produce it. Now I changed to the BitmapPoolAdapter and it seems okay for the first blink but i'm still checking. I'll get back to you, once it is cleared.

[gbrbks]

I have only one device at my possession right now but it is seems bug free! Thank you vey much for the help! The Glide.setup(new GlideBuilder(context).setBitmapPool(new BitmapPoolAdapter()));
is disabling the Bitmap caching but left the other caching behaviours untouched, am I correct? I'll check the skewing with my other devices tomorrow.

[sjudd]

@hamutarto you can definitely use BitmapPoolAdapter to get the same affect. Thanks @TWiStErRob for pointing that out.

If simply disabling bitmap recycling solves the problem on 4.1.x devices and with bitmap recycling enabled you can't reproduce it on devices running other versions of Android, I'd suspect a framework bug.

That being said I'll definitely look in to it more, thanks for reporting this and I look forward to hearing what happens on your other devies.

@TWiStErRob thanks for the hint about stride. I doubt that we're just getting that wrong somewhere, but it's possible something we're doing is causing undefined behavior or exposing a framework bug that results in the same problem. Definitely helpful to know.

[gbrbks]

Hey!

I checked on every devices here at the office and non of them are producing this error any more. Thank you very much again for the fast replies. One last clue for you: All images were the same sized, and it produced with every images (generated by myself or api given).

Cheers

[sjudd]

I have an idea for a fix, if you get the chance to try testing it, I'd love to confirm. To test you can do the following:

Change your load call and add asBitmap() so you end up with:

Glide.with(context).load(...).asBitmap().into(...)

Then add a custom decoder:

StreamBitmapDecoder decoder = new StreamBitmapDecoder(Downsampler.AT_LEAST,
                    Glide.get(getActivity()).getBitmapPool(), DecodeFormat.ALWAYS_ARGB_8888);

Glide.with(context).load(...).asBitmap().imageDecoder(decoder).into(...);

You should also revert the change you made to use BitmapPoolAdapter for the test.

If just setting ALWAYS_ARGB_8888 fixes the problem as it seems to for me, I'd guess there is a framework bug where the inBitmap's config doesn't match the expected config.

[gbrbks]

On Monday when I get back to the office i'll it out thanks! :)

[sjudd]

Awesome, thanks for checking. I'll close this for now, but please re-open if you can still reproduce after either the test I suggested or after the fix I just committed.

[bubbleguuum]

EDIT: ignore this post, had not seen this apply only to JB.

Doesn't the fix for this issue make the app use more memory due to forced 8888 and more garbage collection ? And also slightly slower disk cache performance due to loading cached images 2x the size (more SD card reads) ? I have never seen this skewing issue on Android 4.4.4. It is probably happening on some older KitKat versions, and might be interesting to enable this fix only for the prior affected versions.

[TWiStErRob]

Regardless of your edit, in general: I think when you're reading a jpeg (even with inSampleSize) it's reading the whole stream because it needs to decode each block to get the merged/downsampled pixels out of them, so unless the cached image is already downsampled it's the same amount of reads for full resolution and downsampled, the only difference is the resulting memory size.