Backport changes related to BitmapRegionDecoder from HoneyComb to
Gingerbread.
Bug: 3309014
////////////////////////////////////////////////////
This is a combination of 7 commits.
Revert "Do not merge."
This reverts commit f7681f84918c27f6a626681ce37ed2a236c44e82.
Change-Id: I46fd710600b1649773eaea2d9abc2b21a592f9a6
Fix a initialization bug in BitmapRegionDecoder.
Change-Id: I6c1151fd34970a84d4de52d664d9a5dc464892c5
Fix segfault when tring to throw IOException.
Change-Id: I530cc4409ba4ca17cec933afad077c5f60ba554f
Fix 3122139, where previewing an attachment for the second time will
fail.
Use AutoFDSeek to mark and restore the position before we read data from
the descriptor.
Change-Id: I3d4f012dce486e19b113bc90a98b94031cfa8195
Add inPreferQualityOverSpeed into BitmapFactory.Options.
The new field allows a developer to use a more accurate by
slightly slower IDCT method in JPEG decode. This in turns improves the
quality of the reconstructed image.
The field by default is not set and thus does not affect existing
applications.
Bug: 3238925
Change-Id: I93d55b7226e47a43e639325cd1a677694d6f2ee4
Unhide inPreferQualityOverSpeed in BitmapFactory.Options.
The new field allows a developer to use a more accurate by
slightly slower IDCT method in JPEG decode. This in turns improves the
quality of the reconstructed image.
The field by default is not set and thus does not affect existing
applications.
Bug: 3238925
Related changes: https://android-git.corp.google.com/g/#change,83291 and
https://android-git.corp.google.com/g/#change,83294
Change-Id: I969f5c413f9b2179454aeb90e18ae8222ee583b4
Correct the API comments.
BitmapRegionDecoder supports PNG as well.
Fix 3052285 by not publishing the BitmapRegionDecoder API until the honeycomb release.
Bug: 3052285
Change-Id: Ie339e414c1a5581e1d38684621e0e97162616977
1. Rename LargeBitmap to BitmapRegionDecoder
2. Move the instantiations of BitmapRegionDecoder out of BitmapFactory.
3. Remove the use of MemoryFile in BitmapRegionDecoder, since MemoryFile's API had been modified in master. Otherwise, the change will break the master build.
4. Move AssetStreamAdaptor, AutoFDSeek and nullObjectReturn to Utils.h because BitmapFactory.cpp and BitmapRegionDecoder.cpp both need to use these utility functions.
Most of the modifications, except for (2) and (3), were reviewed in https://android-git.corp.google.com/g/#change,64716 .
However, that change broke the master build due to (3) and was reverted eventually.
So, instead of withdrawing this change and waiting for that change to be checked in again, I merge the two changes into one.
Change-Id: I2202c0fbbbd6d6676bbd9637e690023ea4099c40
In nativeCreateLargeBitmapFromFileDescriptor() if the file descriptor
can not be rewinded isShareable should be set to false.
Change-Id: I7dd545c9d52d21c226e11b8921e35a1d9bba9515
Working on speeding up our NIO implementation, I came across this suboptimal
code. Happily, it turns out to be unused.
Bug: 2935622
Change-Id: I07ae6e573d63e439f496d55af215b34598d8258a
Move AssetStreamAdaptor, AutoFDSeek and nullObjectReturn to Utils.h because
BitmapFactory.cpp and BitmapRegionDecoder.cpp both need to use these utility functions.
Change-Id: I3e60c7fe4abd0289e1384e69a08fd20fe6fb0e10
Before this change, all framework assets would be decoded at drawing time
outside of zygote. This was forcing all apps to re-decode the assets and
zygote to keep an in-memory copy of each asset. This behavior is now
opt-in by setting the inPurgeable flag on BitmapFactory.Options.
Change-Id: Ief823139163d8071b8ee1267746622faf52eb8ec
We see abort messages like this when using JavaPixelAllocator and JavaMemoryUsageReporter.
W/dalvikvm( 680): JNI WARNING: threadid=2 using env from threadid=10
W/dalvikvm( 680): in Landroid/graphics/LargeBitmap;.nativeClean (I)V (CallVoidMethodV)
To fix it, we keep JavaVM, rather than JNIEnv, in JavaPixelAllocator and JavaMemoryUsageReporter,
because JavaVM allows us to get the JNIEnv corresponds to the current thread.
Change-Id: Ibd4b394a53dd3fdccc5a442eeb0dedf836479575
Downloading images over a slow connection could result in errors and
null images.
The JavaInputStreamAdaptor::do_skip method was correctly called in a
loop (to handle the EOF case using read()), but the amount that was
skipped at each time was not decreased by the amount already skipped.
Bug http://code.google.com/p/android/issues/detail?id=6066
Cherry picked from master CL57808
Change-Id: Ie6856898b21ba31de1209e1f995b4ae784c919b9
Adds a mechanism to tell Paint the scaling factor its target
canvas will have, for it to compute font metrics based on the
correct font size. Only TextView uses this, but that is enough
for the large majority of apps.
Change-Id: I6cacaa0dd26d40ee3ad959bed0028678d6e9016e
Remove the stuff that doesn't use preloaded drawables when in
compatibility mode, since this works fine ever since we were able
to deal with drawables in a different density than the canvas.
Change the snapshot function on View to return a snapshot at
the same size that will actually be drawn on screen (when in
compatibility mode), to be able to show scaling artifacts and
all.
This change was original an attempt to fix issue #2101917: Text
field edges appears to be improperly rounded. That turns out to
probably be something deeper in the graphics system, but also
included here is the debugging code I did to try to track down the
problem to make it easy to turn on again later.
Change-Id: I34bfca629639c7ff103f3989d88874112ef778d9
Previously we had been setting the imageSize parameter to 0, which was
incorrect. According to the OpenGL ES spec for glCompressedTexImage2D
this parameter should be the size in bytes of the compressed data.
Merge commit '6af2552d244ff933dfd54570121db455cc7c3cda'
* commit '6af2552d244ff933dfd54570121db455cc7c3cda':
use safeUnref() since the other macro is not defined in donut
Merge commit '7299d6ad9820bbb601034542c94d6dc73cc4829d'
* commit '7299d6ad9820bbb601034542c94d6dc73cc4829d':
check for null native objects, which never happens on a real subclass (we throw in that case)
* changes:
check for null native objects, which never happens on a real subclass (we throw in that case) but can happen because we allow the callers to create the base class from java.
It turns out we were not returning the density for anything retrieved from a
TypedArray... which basically means any bitmap references from a layout or style...!!!
This is now fixed.
Also fiddle with the density compatibility mode to turn on smoothing in certain situations,
helping the look of things when they need to scale and we couldn't do the scaling at
load time.
Merge commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8'
* commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8':
Allow for screen density drawables in compatibility mode.
This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.
This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).
As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
