diff --git a/docs/downloads/training/BitmapFun.zip b/docs/downloads/training/BitmapFun.zip index 48bea7805cd86..8668897f99018 100644 Binary files a/docs/downloads/training/BitmapFun.zip and b/docs/downloads/training/BitmapFun.zip differ diff --git a/docs/html/training/displaying-bitmaps/cache-bitmap.jd b/docs/html/training/displaying-bitmaps/cache-bitmap.jd index ad084c25458bb..ff9c3a0415c6e 100644 --- a/docs/html/training/displaying-bitmaps/cache-bitmap.jd +++ b/docs/html/training/displaying-bitmaps/cache-bitmap.jd @@ -188,8 +188,8 @@ appropriate place to store cached images if they are accessed more frequently, f image gallery application.

The sample code of this class uses a {@code DiskLruCache} implementation that is pulled from the -Android source. Here’s updated example code that adds a disk cache in addition -to the existing memory cache:

+Android source. +Here’s updated example code that adds a disk cache in addition to the existing memory cache:

 private DiskLruCache mDiskLruCache;
diff --git a/docs/html/training/displaying-bitmaps/load-bitmap.jd b/docs/html/training/displaying-bitmaps/load-bitmap.jd
index 633ffd2df7720..938901f8c74ed 100644
--- a/docs/html/training/displaying-bitmaps/load-bitmap.jd
+++ b/docs/html/training/displaying-bitmaps/load-bitmap.jd
@@ -97,7 +97,8 @@ android.graphics.BitmapFactory.Options} object. For example, an image with resol
 is decoded with an {@link android.graphics.BitmapFactory.Options#inSampleSize} of 4 produces a
 bitmap of approximately 512x384. Loading this into memory uses 0.75MB rather than 12MB for the full
 image (assuming a bitmap configuration of {@link android.graphics.Bitmap.Config ARGB_8888}). Here’s
-a method to calculate a the sample size value based on a target width and height:

+a method to calculate a sample size value that is a power of two based on a target width and +height:

 public static int calculateInSampleSize(
@@ -107,26 +108,26 @@ public static int calculateInSampleSize(
     final int width = options.outWidth;
     int inSampleSize = 1;
 
-    if (height > reqHeight || width > reqWidth) {
+    if (height > reqHeight || width > reqWidth) {
 
-        // Calculate ratios of height and width to requested height and width
-        final int heightRatio = Math.round((float) height / (float) reqHeight);
-        final int widthRatio = Math.round((float) width / (float) reqWidth);
+        final int halfHeight = height / 2;
+        final int halfWidth = width / 2;
 
-        // Choose the smallest ratio as inSampleSize value, this will guarantee
-        // a final image with both dimensions larger than or equal to the
-        // requested height and width.
-        inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
+        // Calculate the largest inSampleSize value that is a power of 2 and keeps both
+        // height and width larger than the requested height and width.
+        while ((halfHeight / inSampleSize) > reqHeight
+                && (halfWidth / inSampleSize) > reqWidth) {
+            inSampleSize *= 2;
+        }
     }
 
     return inSampleSize;
 }
 
-

Note: Using powers of 2 for {@link -android.graphics.BitmapFactory.Options#inSampleSize} values is faster and more efficient for the -decoder. However, if you plan to cache the resized versions in memory or on disk, it’s usually still -worth decoding to the most appropriate image dimensions to save space.

+

Note: A power of two value is calculated because the decoder uses +a final value by rounding down to the nearest power of two, as per the {@link +android.graphics.BitmapFactory.Options#inSampleSize} documentation.

To use this method, first decode with {@link android.graphics.BitmapFactory.Options#inJustDecodeBounds} set to {@code true}, pass the options diff --git a/docs/html/training/displaying-bitmaps/manage-memory.jd b/docs/html/training/displaying-bitmaps/manage-memory.jd index 60ac2e6d9188e..0e1279e970433 100644 --- a/docs/html/training/displaying-bitmaps/manage-memory.jd +++ b/docs/html/training/displaying-bitmaps/manage-memory.jd @@ -56,7 +56,7 @@ bitmap is stored in native memory. It is separate from the bitmap itself, which is stored in the Dalvik heap. The pixel data in native memory is not released in a predictable manner, potentially causing an application to briefly exceed its memory limits and crash. -As of Android 3.0 (API Level 11), the pixel data is stored on the +As of Android 3.0 (API level 11), the pixel data is stored on the Dalvik heap along with the associated bitmap. @@ -140,27 +140,16 @@ private synchronized boolean hasValidBitmap() {

Manage Memory on Android 3.0 and Higher

-

Android 3.0 (API Level 11) introduces the +

Android 3.0 (API level 11) introduces the {@link android.graphics.BitmapFactory.Options#inBitmap BitmapFactory.Options.inBitmap} field. If this option is set, decode methods that take the {@link android.graphics.BitmapFactory.Options Options} object will attempt to reuse an existing bitmap when loading content. This means that the bitmap's memory is reused, resulting in improved performance, and -removing both memory allocation and de-allocation. There are some caveats in using -{@link android.graphics.BitmapFactory.Options#inBitmap}:

-