| 91f0a455bb6670b59b8d15cc7a9adb0e6d7f146d |
|
21-Mar-2014 |
John Reck <jreck@google.com> |
Eliminate mHasAlpha
Bug: 13580771
The cached value mHasAlpha on Bitmap could get out of sync with the
real value stored in the SkBitmap. Fix this by just eliminating the
cached value. This adds an extra JNI call in copy(), createBitmap(),
and setPremultiplied(), none of which are going to be significantly
impacted by the extra JNI call.
Change-Id: I4fce069a77d9b3bbb47dde04275ff8510ce7e4f0
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 92a3283286df3a6c2a27ecde8eddf23abbb87de9 |
|
15-Jan-2014 |
Leon Scroggins III <scroggo@google.com> |
DO NOT MERGE - Fix Javadoc build break.
Remove links to non-specific function name.
Bug: 13246311
Change-Id: I5643074149d0a511bd760d638751c44e3ec4c557
(cherry picked from commit 2bc49ca96eb786f66dc2b9573e1f09bdb2d82d5e)
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 5e49b497ae2019586937aae0e8159292363728b5 |
|
03-Dec-2013 |
Leon Scroggins III <scroggo@google.com> |
Update framework to use M33 Skia. DO NOT MERGE
(These CLs are already in master.)
Bug: 13246311
This cherry-picks 7 CLs:
-----------------------------------------------------------------------
Remove calls to deprecated SkBitmap::setIsOpaque()
setIsOpaque() has been removed from ToT Skia.
Update setters for mIsPremultiplied and hasAlpha to take the
other into consideration.
cherry-pick from: I1b36b0b0ce7126031eb7b769b563c17dcd4b306a
-----------------------------------------------------------------------
Merge AssetStream with AssetStreamAdaptor.
Add enums to the constructor for AssetStreamAdaptor to choose the
different behaviors used by the (former) two different classes.
The old clients of AssetStream now get the following features of
AssetStreamAdaptor
- Debugging statements on error.
- The stream is an SkStreamRewindable.
- getLength() returns the correct value, and the old way of getting
the length (read(NULL, 0)) is no longer implemented, since it is
no longer used.
- isAtEnd() returns the correct value. ToT Skia makes it pure virtual,
so some implementation is necessary.
cherry-pick from: I2a5395914e4f53830aaefee396556459083a1c56
-----------------------------------------------------------------------
Deprecate Android-specific SkPaint functions.
The following functions were problematic:
const SkGlyph& getUnicharMetrics(SkUnichar, const SkMatrix*);
const SkGlyph& getGlyphMetrics(uint16_t, const SkMatrix*);
const void* findImage(const SkGlyph&, const SkMatrix*);
Replacing them with calls through SkGlyphCache solved a nasty crash
bug, so they have all been deprecated.
Bug: 11968757
cherry-pick from: Id746315d41aec5b211b78b172a883c2061130f08
-----------------------------------------------------------------------
pass SkGlyphCache into updateGlyphCache()
Doing so prevents us from double-locking the glyph cache, thereby
effectively locking ourselves out of reusing work that we'd just done.
Bug: 11968757
cherry-pick from: I5c552f2d0bbe30af2ce9054ba684e7da756a0d89
-----------------------------------------------------------------------
Updates to the Skia API needed to merge the WebView m33 version of Skia.
cherry-pick from: I0f63b53f2aae58871413b132742fc84138f069a3
Bugfix for screenshots (recent apps) due to incorrect rowBytes computation
bug: 12915192
cherry-pick from: I4d5fe2a2f75baf66099e0970fb646686a1992714
-----------------------------------------------------------------------
Fix bug in AndroidPixelRef where we did not store the correct imageInfo for a recycled bitmap.
cherry-pick from: I882483b78886e2f19fa4e43a86e69f5a82b3b7e5
-----------------------------------------------------------------------
Change-Id: Ie2b731a9f0795802418cfecddb4b684c92c64d33
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 222f2ad294c9046b62af5e059f8b409aec044ce9 |
|
06-Nov-2013 |
Chris Craik <ccraik@google.com> |
Fix NPE with inPurgeable Bitmaps in getAllocationByteCount
bug:11556330
Change-Id: I430136ea15baeb60adfb9bb2acdde9505ce707fe
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| e8222dddaf2e3da14380101e818d4254899e0c0d |
|
05-Sep-2013 |
Chet Haase <chet@google.com> |
Change build version from KEY_LIME_PIE to KITKAT
Issue #10631619 Change build version to KitKat
Change-Id: I6ad13f6169ad74204078d36929479998b498ad8b
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 25ba1c86945a441428194d9ebcabbf31be75a45a |
|
03-Sep-2013 |
Romain Guy <romainguy@google.com> |
Update Bitmap.Config.ARGB_4444 documentation
Bug #10510122
ARGB_4444 is deprecated and always replaced with ARGB_8888.
Change-Id: I0da96216af701a7df00ad35913066fbfa997d790
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 1abf5d62429e5a9329520b2f7c2b5a5e7a8e72ec |
|
16-Aug-2013 |
Chris Craik <ccraik@google.com> |
Add inPremutiplied option to BitmapFactory.Options, functionality in Bitmap
bug:2248948
Change-Id: I8fdd649332667598504a1076d5a447572bd53086
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 790552b240c05d58407f7c14acba656b2e85c523 |
|
12-Aug-2013 |
Romain Guy <romainguy@google.com> |
Update Bitmap.createBitmap() documentation
Change-Id: Ic2efed6cc03c8b2c2d9810b7ab645b0b98b91e1f
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 9c2cde0583d02ba7551877dbe7a5ecaee6defb56 |
|
23-Jul-2013 |
Chris Craik <ccraik@google.com> |
Use IllegaleStateException to be consistent with rest of Bitmap class
Change-Id: Idd1c77f92eafa8a43619d27a9567382447540e5f
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| c84d203da21c3ae3ded94c79c035d41b27809b3b |
|
13-Jul-2013 |
Chris Craik <ccraik@google.com> |
Add reconfigure method to Bitmap
bug:9797004
Grants a means to reuse a bitmap's allocation for different
width/height/Config without going through
BitmapFactoryOptions.inBitmap
Change-Id: Ib62319f3bd96c451fc1636288adf06a8275b4e3d
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 0c20c3898a533b7b76f60827cb6ea02e17c5953d |
|
02-Jul-2013 |
Chris Craik <ccraik@google.com> |
Use global references for Bitmap AndroidPixelRefs
bug:9621717
Because we're no longer holding onto Bitmaps Java side during
DisplayList lifetime, use global refs to keep the backing byte arrays
around.
Adds back bitmap buffer passing + native ref management removed by
3b748a44c6bd2ea05fe16839caf73dbe50bd7ae9
Adds back globalRef-ing removed by
f890fab5a6715548e520a6f010a3bfe7607ce56e
Change-Id: Ia59ba42f05bea6165aec2b800619221a8083d580
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 9f58361e98be7386a4eadd3aa254e9b7d09d0a3b |
|
21-May-2013 |
Chris Craik <ccraik@google.com> |
Support larger bitmaps in BitmapFactory.Options.inBitmap
bug:8121994
Adds a new distiction between bitmap size and the allocation
(pixel ref/buffer) used to store its data.
BitmapFactory.inBitmap will allow a bitmap to be reinitialized with
new data if the bitmap being decoded is (after sampleSize) equal or
smaller.
Change-Id: I747750a735c858882df3af74fca6cdc46f2a9f81
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 3b748a44c6bd2ea05fe16839caf73dbe50bd7ae9 |
|
18-Apr-2013 |
Romain Guy <romainguy@google.com> |
Pack preloaded framework assets in a texture atlas
When the Android runtime starts, the system preloads a series of assets
in the Zygote process. These assets are shared across all processes.
Unfortunately, each one of these assets is later uploaded in its own
OpenGL texture, once per process. This wastes memory and generates
unnecessary OpenGL state changes.
This CL introduces an asset server that provides an atlas to all processes.
Note: bitmaps used by skia shaders are *not* sampled from the atlas.
It's an uncommon use case and would require extra texture transforms
in the GL shaders.
WHAT IS THE ASSETS ATLAS
The "assets atlas" is a single, shareable graphic buffer that contains
all the system's preloaded bitmap drawables (this includes 9-patches.)
The atlas is made of two distinct objects: the graphic buffer that
contains the actual pixels and the map which indicates where each
preloaded bitmap can be found in the atlas (essentially a pair of
x and y coordinates.)
HOW IS THE ASSETS ATLAS GENERATED
Because we need to support a wide variety of devices and because it
is easy to change the list of preloaded drawables, the atlas is
generated at runtime, during the startup phase of the system process.
There are several steps that lead to the atlas generation:
1. If the device is booting for the first time, or if the device was
updated, we need to find the best atlas configuration. To do so,
the atlas service tries a number of width, height and algorithm
variations that allows us to pack as many assets as possible while
using as little memory as possible. Once a best configuration is found,
it gets written to disk in /data/system/framework_atlas
2. Given a best configuration (algorithm variant, dimensions and
number of bitmaps that can be packed in the atlas), the atlas service
packs all the preloaded bitmaps into a single graphic buffer object.
3. The packing is done using Skia in a temporary native bitmap. The
Skia bitmap is then copied into the graphic buffer using OpenGL ES
to benefit from texture swizzling.
HOW PROCESSES USE THE ATLAS
Whenever a process' hardware renderer initializes its EGL context,
it queries the atlas service for the graphic buffer and the map.
It is important to remember that both the context and the map will
be valid for the lifetime of the hardware renderer (if the system
process goes down, all apps get killed as well.)
Every time the hardware renderer needs to render a bitmap, it first
checks whether the bitmap can be found in the assets atlas. When
the bitmap is part of the atlas, texture coordinates are remapped
appropriately before rendering.
Change-Id: I8eaecf53e7f6a33d90da3d0047c5ceec89ea3af0
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 1f58497e7dbab1b16e97c73b65559b852d0c2803 |
|
26-Nov-2012 |
Romain Guy <romainguy@google.com> |
Clarify Bitmap.copyTo/FromPixelBuffer documentation
Change-Id: Ifb410df392a5ad6c83d6744e19aad13b9a4e811d
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 547e66531d521eb1eadac87edb0f79f8c2f1bbe0 |
|
23-Oct-2012 |
Chet Haase <chet@google.com> |
Don't null the reference to Bitmap pixels until we're really ready
A change in the VM triggers a native memory error more aggressively than before,
showing that there's a bug in the logic of recycling bitmaps. Since the pixel
memory is allocated on the Java heap, nulling out the reference to that memory
in the Java level Bitmap object can cause that memory to get collected at any time.
Meanwhile, we may have a reference to that memory at the native level for rendering
purposes, causing an error if/when we access that memory after it has been collected
by the VM.
The fix is to avoid setting the reference to the pixels to null unless we are
not referring to it in native code. This is determined at the time we call
recycle() - we return a boolean to indicate whether the native code is still
using the memory. if not, the Java code can null out the reference and allow the
VM to collect it. Otherwise, it will get collected later when the encompassing
Bitmap object is collected.
Issue #7339156 HTML5 tests crash the app (Vellamo)
Change-Id: I3a0d6b9a6c5dd3b86cc2b0ff7719007e774b5e3c
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 713e1bb9df6bdfc21bd5c40d1a6ecf6c822a4be5 |
|
17-Oct-2012 |
Romain Guy <romainguy@google.com> |
Add API to enable mipmaps on Bitmap
Bug #7353771
This API can be used when scaling large images down to a small size
to get nicer looking results.
Change-Id: If09087eed36077eee5355f6047a3ca67747d7d9e
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 0b68477f8287fe5ddac1beb1c9d0811ded034dad |
|
12-Oct-2012 |
Romain Guy <romainguy@google.com> |
Don't scale bitmaps to an empty size when targetDpi=0
Bug #7334217
Change-Id: I8d232a835580ffbf85334e0a3580e8d8240c8570
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 55adc145d460be4b21de0d77be1f6076c3591e3c |
|
08-Oct-2012 |
Marco Nelissen <marcone@google.com> |
Adjust buffer position after copying
Make Bitmap.copyPixelsFromBuffer() adjust the buffer's position,
making it consistent with Bitmap.copyPixelsToBuffer().
b/6948775
Change-Id: Ie26f8050b1fb4d19cd39ee1a08b6f652a732fec3
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 4ff0cf4b83605bff630c4e6f1fabe4f72a3f93a1 |
|
06-Aug-2012 |
Romain Guy <romainguy@google.com> |
Add new debug tool to track hardware layers updates
You can setprop debug.hwui.show_layers_updates true to flash
hw layers in green when they update. This is also a setting
in the Dev. section of the settings app.
Change-Id: Ibe1d63a4f81567dc1d590c9b088d2e7505df8abf
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| dde331cebd87982faded6818ad5f9927ff994c96 |
|
03-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
We can now (kind-of) change screen density on the fly.
Preloaded drawables now have a density associated with them, so we
can load the correct drawable if we are using a different density.
Window manager now formally keeps track of the density for each
screen, allowing it to be overridden like you can already do with
size, and relies on this density to drive itself internally and
the configurations it reports.
There are a new set of Bitmap constructors where you provide a
DisplayMetrics so they can be constructed with the correct density.
(This will be for when you can have different windows in the same
app running at different densities.)
ActivityThread now watches for density changes, and pushes them
to the DENSITY_DEVICE and Bitmap global density values for that
process.
A new am command allows you to change the density.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 3849f93b3c2b29ca3873b602897dccac039a0b98 |
|
09-Jul-2012 |
Romain Guy <romainguy@google.com> |
Add Bitmap.isPremultiplied()
This change also adds extra information in the documentation about
premultiplied values.
Change-Id: I51aacb8696340d23354ebf6d7284605d1a790b69
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 17471d730f20ee785c9c48a99eb331a40550612b |
|
06-Apr-2012 |
Romain Guy <romainguy@google.com> |
Fix javadoc
Change-Id: I41315ff2ff1b404de82264e6a56ee46032862a32
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| ec4a50428d5f26a22df3edaf7e5b08f41d5cb54b |
|
04-Apr-2012 |
Amith Yamasani <yamasani@google.com> |
Embed layout padding in nine patch images
- Added a new custom PNG chunk that carries the layout padding ints.
- Extract the padding ticks from .9.png images and store in the chunk.
- Load the padding information at runtime into Bitmap and NinePatchDrawable.
- The new chunk is ordered first so that it doesn't cause a problem in older
versions of the platform.
Bug: 6087201
Change-Id: I5de46167a1d44b3ec21065b0c165e594b1dc8399
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| f12f6f058f169ead83a546a1c3a51e49452a30b3 |
|
15-Feb-2012 |
Romain Guy <romainguy@google.com> |
Clarify documentation of Bitmap.createScaledBitmap/createBitmap
Bug #6015472
Change-Id: I6cf9efc2f695928d54a0dfba08b085559574ae14
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 1373a8eb581fe3c8e9a036e69042015f98a7e346 |
|
11-Nov-2011 |
Christopher Tate <ctate@google.com> |
Localized optimizations in views and bitmaps
* Don't call context.getResources() redundantly when unnecessary;
similarly for Resources.getCompatibilityInfo()
* During bitmap creation, don't bother clearing to 0: it's unnecessary
because now that the raw bits are stored in a VM-side byte array, it
was cleared at initialization time. Also, don't use the sanity-
checking public entry point to erase to a color, because we know
that we're by definition in a "legal" path to erase to the initial
contents and don't need to incur the overhead of the (inappropriate)
sanity checking.
Change-Id: Idaca4d64fdecefd5d51337646ead32e1db510e02
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| b6377170960d40e66858d8b4d335a95eac773762 |
|
25-Sep-2011 |
Bart Sears <bsears@google.com> |
Revert "Transfer large bitmaps using ashmem. Bug: 5224703"
This reverts commit 56c58f66b97d22fe7e7de1f7d9548bcbe1973029
This CL was causing the browser to crash when adding bookmarks, visiting the bookmarks page, and sharing pages (see bug http://b/issue?id=5369231
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 56c58f66b97d22fe7e7de1f7d9548bcbe1973029 |
|
24-Sep-2011 |
Jeff Brown <jeffbrown@google.com> |
Transfer large bitmaps using ashmem.
Bug: 5224703
Change-Id: Ic7481dd9f173986f085a8bbdcc59bbe9830d7a44
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 7f9f99ea11051614a7727dfb9f9578b518e76e3c |
|
11-Aug-2011 |
Xavier Ducrohet <xav@android.com> |
Make some methods/fields package private so that layoutlib can access them.
Change-Id: I4aeadfbaf8a4f6a459fa19937c21ac23d9e5fb64
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 6311d0a079702b29984c0d31937345be105e1a5e |
|
03-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Clear the bitmap from the canvas in a lot of places.
Change-Id: I6b2071ac7b348c473b9bdd1b972d095aebbb4fb3
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| ec5039b3720ee9b92fb2a2c6dd9f468d2dcd7172 |
|
24-Jun-2011 |
Jean-Baptiste Queru <jbq@google.com> |
am 99c070d8: am 4fea5373: Merge "Add WEBP to the list of Image formats that support Compression."
* commit '99c070d8eb9f1ff9ea5c38991f15f091040226c2':
Add WEBP to the list of Image formats that support Compression.
|
| 2305ac9e4a262ed09fd034ae417e9b1dda4c0ccb |
|
23-Jun-2011 |
Vikas Arora <vikasa@google.com> |
Add WEBP to the list of Image formats that support Compression.
Note: The integrator of this change to Android internal code-repo will
have to run one extra step 'make update-api' to update 'api/current.txt'
file corresponding to approved API. The AOSP branch didn't have this
file, hence I could not add the same to this change. The updated file
'api/current.txt' has to be submitted along with this change.
Change-Id: I29909e907a2e82d801e16654322190a808c5bda9
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| f7f9d9c39df22ad6929f001f07588469f77e8bf5 |
|
17-Feb-2011 |
Jesse Wilson <jessewilson@google.com> |
Expose an API to get a bitmap's size in bytes.
Change-Id: I960c3b02b1ba8d3a8d92aaa98955a159e6f3a228
http://b/3184897
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 676b17391fb6583e5df944c36b1bd4c1be835689 |
|
14-Feb-2011 |
Romain Guy <romainguy@google.com> |
Deprecate ARGB_4444.
It looks awful.
Don't use it.
Use ARGB_8888, it's much better.
If you think you need ARGB_4444, you are wrong.
You are.
Change-Id: I4d6963cf98b6a8fb34cebcd0d24b9fd66b5a0fbf
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 366a84056c9a695ee6702d9d30bf9f3b521ba7cc |
|
08-Feb-2011 |
Romain Guy <romainguy@google.com> |
Expose several useful Bitmap APIs.
Bug #3408073
Bitmap.setHasAlpha() in particular is very useful for applications that use
ARGB_8888 bitmaps but want/need to benefit from an extra speed boost.
Change-Id: I73d081b7e43bd725baffd1a9892c72d8729816f7
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| feeea8f07c854e6b0ae2fec3aa2d239c17f32b5b |
|
01-Feb-2011 |
Romain Guy <romainguy@google.com> |
Assume ARGB_8888 for unknown configs.
Bug #3327175
Change-Id: If712a255ec65014cd2e007de1e4c6a1d67c19250
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| f6a362a5f65c1470399d869f0c39caac40e561a3 |
|
01-Feb-2011 |
Romain Guy <romainguy@google.com> |
Don't convert 4444 images to 565.
Bug #3327175
Change-Id: I46d970e41947278f4c2476b347fd2403fe9a05e8
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| a383b3f646cbc1fd870f2694d4fac24340834916 |
|
21-Jan-2011 |
Patrick Dubroy <dubroy@google.com> |
Update Bitmap.recycle() doc for heap-allocated pixel data
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 2361098da3b9d9c3eeed410dc72ba62c0e9177cf |
|
17-Jan-2011 |
Romain Guy <romainguy@google.com> |
Add BitmapFactory.Options.inMutable to load mutable bitmaps.
Change-Id: Iaa222127520f3aa55072d44af12ee3477908b876
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| e4ac2d6b5723c95e648c489b187ddde449452c13 |
|
01-Dec-2010 |
Patrick Dubroy <dubroy@google.com> |
Allocate bitmap backing buffers in the Java heap.
Change-Id: I60f6ccff13357c1c518e9d56b02fe0171637edd1
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 5e9f64ce24b3381ee48f9e12242aba5216f136a4 |
|
04-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
am b12bfbd4: am eb6e22f2: Merge "Document Bitmap.createScaledBitmap" into gingerbread
Merge commit 'b12bfbd4df985041ab0e584ef5a746328baac038'
* commit 'b12bfbd4df985041ab0e584ef5a746328baac038':
Document Bitmap.createScaledBitmap
|
| 02d9102b3bdebac6989c2b7d12c080fb7c1f8e2b |
|
04-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Document Bitmap.createScaledBitmap
Change-Id: Ife6a42bc08d17c56274e78a1f5d2c100c2fe4dc8
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| d90f23e24a4d1768d5a7ed0e7072e67af6330a45 |
|
09-Sep-2010 |
Romain Guy <romainguy@google.com> |
Do not convert 8888 bitmaps to 565 when doing a copy.
Bug #2988077
This change keeps the 8888 format for new bitmaps and also keeps,
when possible, the opaque flag.
Change-Id: Ia61f2e89936916b329212a4c59a7d815c329f84e
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 601ede9aa3337bb6d54dfb0633b54835421b5720 |
|
21-Aug-2010 |
Chih-Chung Chang <chihchung@google.com> |
Revert "Don't recycle native bitmap after the finalizer is called."
Bitmap should not be accessed from multiple threads.
This reverts commit 966803ab81f8e9bfefa502fcb533de023825a389.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 966803ab81f8e9bfefa502fcb533de023825a389 |
|
20-Aug-2010 |
Chih-Chung Chang <chihchung@google.com> |
Don't recycle native bitmap after the finalizer is called.
If an object A's finalizer calls Bitmap B's recycle() when B's
finalizer is already called, we will have trouble because the
native bitmap is already freed in the finalizer.
Change-Id: Ic0be8ed75fb3aacee9ce6e3d9908178a55151eb9
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 02890fd0f98b3b8d98baf0bda1ea906afd723d8b |
|
07-Aug-2010 |
Romain Guy <romainguy@google.com> |
Replace Bitmap's finalizers with PhantomReferences.
This change also removes the use of SoftReferences for View's
drawing cache.
A bitmap now creates a PhantomReference enqueued in a reference
queue provided by the new Finalizers class. This queue is polled
from a thread started after forking zygote. That thread is in charge
of clearing the references after GC runs and of calling reclaim()
on them. The reclaim() method is now how finalizers are run.
Note that a PhantomReference cannot be kept in the instance it
refers to, which is why they are kept in a separate List.
Change-Id: If3c1a5e9dc23fa49e34857860d730f5cf5ad5926
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| ce0537b80087a6225273040a987414b1dd081aa0 |
|
30-Jun-2010 |
Romain Guy <romainguy@google.com> |
Add hooks for drawBitmap().
Change-Id: I58e962c3a8b2bc75c2605fe369ad3002579d86e0
Add texture cache.
Change-Id: I1c0e5581d228869e114438258a1014e33e024ad7
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 0bbae0836426ba2704e38e7f90a9d0ca502ab71d |
|
16-Jun-2010 |
Romain Guy <romainguy@google.com> |
Add new API to check whether a Bitmap was modified.
Bitmap.getGenerationId() can be used by caches to find out if a Bitmap has been
modified. This simply exposes an existing Skia API.
This change also adds a small test app for Canvas hardware acceleration. The new
Bitmap API is required to implement a texture cache.
Change-Id: I8547b146cd14c8afe1a2327fcd6d71b1b1cb68fc
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 76d1e01d5e65c4631c827831e98ad4e300d99eab |
|
05-Mar-2010 |
Mike Reed <reed@google.com> |
hidden api sameAs() to compare the pixels of 2 bitmaps for equality
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| a78b0a2d9ebb38b86ed802b3d86de07d0b301262 |
|
07-Oct-2009 |
Mike Reed <reed@google.com> |
add (hidden) setHasAlpha() to allow clients like the view's cache to hint that a bitmap is opaque.
Knowing that a 32bit bitmap is opaque is a performance boost for some blits.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| de0dfb7b65a02d4dd74c271b558adee0973fc267 |
|
23-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2125720 Weather Forecast Widget - graphics do not scale
I forgot to add the new density field to the Bitmaps' parcelable data.
Change-Id: I77cf3e93e356297e0caed6fc71b62b5cd8f79124
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 96e240f25a97c10bba863df328ed73a82c34ff61 |
|
27-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Fiddle with default densities to try to sanitize the API.
An issue with the density API is that bitmaps assumed the old default density,
so new programs would have to explicitly set the correct density for every bitmap
they create.
This is an attempt to fix that situation, by define the default density of bitmaps
to be the main screen's density, except for old apps where it is the original default
density.
Actually implementing this is not so great, though, because the Bitmap constructors
can't really know anything about who is calling them to know which density to use.
So at this level the compatibility mode is defined per-process -- meaning the initial
package loaded into a process defines the default bitmap density, and everyone else
loaded in later on has to live with that.
In practice this shouldn't be much of a problem, there shouldn't be much mixing of
old vs. new apps in a process. It does mean that, going forward, if a developer is
going to use shared user IDs for this, they will need to make sure either that all of
their apps are in the same compatibility mode, or that their code explicitly sets the
density of bitmaps it receives. This isn't all that great, but I think it is worth
the benefit of allowing people who write modern apps to not have to deal with bitmap
densities.
This change also does some cleanup of the density management (making sure to always
copy over bitmap densities, etc) and adds java docs to explain the various ways
density is set and used by the system.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 11ea33471e1a14a8594f0b2cd012d86340dd3bd8 |
|
23-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
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.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 2784ff0af88128f66ae690b73d48fb7e4a211e68 |
|
19-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue where scaled bitmap sizes could be wrong.
The Bitmap functions to get the scaled width/height couldn't actually
do the right thing because they didn't know the destination they would
be drawing to. Now there are two forms of them, taking an explicit
parameter specifying the destination.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| a53b828635fce8b6b2d3e3377d74d72070056623 |
|
17-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Add "nodpi" density, and expose a bunch of density-related APIs.
Also update the DpiTest app to use nodpi images, and try to have a mode
where it turns off compatibility though it's not quite working.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 8cdcb12752b716d0407733fecefcf1d9e926310a |
|
18-Jun-2009 |
Wei-Ta Chen <weita@google.com> |
Add prepareToDraw() to Bitmap for fixing http://b/issue?id=1907995.
The function is used to rebuild any caches associated with the bitmap.
In the case of purgeable bitmaps, this call ensures that the pixels
are decoded for drawing, and therefore prefetching techniques
implemented by callers can be leveraged.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 60b88edea7132ddce90f2dced07c6706f1502270 |
|
14-May-2009 |
Ken Shirriff <kens@google.com> |
Fix typos.
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| f1e484acb594a726fb57ad0ae4cfe902c7f35858 |
|
22-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@127436
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|