fallback to imprecise scaling if low memory #1892
Conversation
| /** | ||
| * Memory-friendly workaround found from https://code.google.com/p/android/issues/detail?id=6066#c23 | ||
| * to solve decoding problems in bitmaps from InputStreams that don't skip if no more stream is available. | ||
| */ |
There was a problem hiding this comment.
Was this happening? This link is talking about blocking network streams, where as read() from disk should always read the number of bytes requested.
There was a problem hiding this comment.
Ah, wasn't aware. The Javadoc didn't say that read() always returns the number of bytes requested. Seemed like a good idea to make sure it worked with all InputStream objects anyway. Would you prefer I instead have the method signature only take in FileInputStreams?
There was a problem hiding this comment.
The contract is not that strong, but in practice read() will only return short of the requested value if less than the requested value is available. That should only happen when reading from the network. I'm mostly curious how this came up.
There was a problem hiding this comment.
It was a while ago, but I think originally I was experiencing those "decoder false" errors when doing Bitmap work a while back, and wrapping it in a BufferedInputStream seemed to resolve the problem. This is supposedly a more memory-efficient way to do the same thing, and it feels safer to include it.
// FREEBIE
mcginty
force-pushed
the
bitmap-memory
branch
from
cb3513c
to
1b3bd32
Compare
fallback to imprecise scaling if low memory
Gracefully falls back to rough scaling to solve the OutOfMemoryErrors that I was able to reproduce on a GB emulator with low RAM. This helps a lot since it doesn't require two large Bitmap objects in memory at the same time.
Also moved away from BufferedInputStream to another workaround to the Android bitmap problems, which will save more memory. On top of that, we weren't closing the streams so that's also fixed.