| 01a0af31d7d418f400ce5d3f752eba6a35aa00e2 |
|
31-Jul-2015 |
John Reck <jreck@google.com> |
Yell loudly about undefined behind in Bitmap, but work anyway
Bug: 22214367
Previous releases would let the getters on a recycle()'d bitmap to still
work despite being firmly in undefined behavior per the documentation
on Bitmap#recycle().
As there are apps relying on this, yell very loudly about this behavior
in the log and give them a bit of time to fix it
Change-Id: I857be7e74cb217877973d9c6f03eb761d12fd056
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 3df4869a77bdeb72d5810bbcf7819ed1b8dd0ec7 |
|
20-May-2015 |
John Reck <jreck@google.com> |
Fix Bitmap#sameAs NPE
Bug: 21281842
Change-Id: I4a1e33d7e642fa50e8789f1441e8587d1c15119c
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 721ae5fec5f1fd4f93aa2a361a0ac298e15ce353 |
|
12-May-2015 |
Riley Andrews <riandrews@google.com> |
Add internal bitmap api for creating immutable ashmem backed bitmaps.
Bug 21037890
Change-Id: I827e83dd75e301e7d93ead5efdd744f0d8435ae5
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 9298c5414172344f2462beda70e624af5f774483 |
|
11-May-2015 |
John Reck <jreck@google.com> |
Clarify assert
Bug: 20918138
Change-Id: I39a9f8bbfb3752f9a6e5f5215ed8cd3c93ce87fc
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| ad57442fd00e7fd7f1885d23372ec5c85e176820 |
|
11-May-2015 |
John Reck <jreck@google.com> |
Add a few missing asserts
Bug: 20918138
Change-Id: I6823cfe531ff6f63a7d9fde22278e6780726c9f1
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 3e776dee3e8af646cdcfb7a60e0e301c99f05293 |
|
08-May-2015 |
John Reck <jreck@google.com> |
Compatibility hack
Bug: 20940526
Rather than throwing an exception on accessing a recycled()
bitmap let certain operations succeed and just return dummy
values. Apps appear to be relying on this.
Change-Id: I74df2efdc29d93facd8553ed31cda3addf0b28eb
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| f29ed28c7b878ef28058bc730715d0d32445bc57 |
|
07-Apr-2015 |
John Reck <jreck@google.com> |
Attempt to solve the double-GC problem
Fix the issue where Bitmap requires two GC passes
to release its byte[] by using some questionable
ref-counting hacks to manage whether or not
native has a strong or weak ref to the byte[]
Change-Id: Ia90a883579f61c0b1904b5549a66bd0ef34b32c5
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 7c103a36f60b690e3fe83c40210e1cb0c76bba43 |
|
16-Apr-2015 |
John Reck <jreck@google.com> |
Remove Bitmap#getSkBitmap
Change-Id: Ifb9047b426122d3e5a445eb7a0eb3fce38dedf27
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| c6e2e8ff474ae44bab5b9eb665851118abd27b68 |
|
15-Apr-2015 |
John Reck <jreck@google.com> |
Move AssetAtlas off of SkBitmap*
Switched to SkPixelRef*
Change-Id: I4a1d9dc6c55c1ebcce6b0b8c585e69559e523898
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 7809f835cae637c12eebdc92103ad88890228d97 |
|
17-Apr-2015 |
John Reck <jreck@google.com> |
Revert "Move AssetAtlas off of SkBitmap*"
This reverts commit 87ffb63d90fb6dd2689fe72dcb24fda9a6156220.
Change-Id: I92adfcee454a0a19020cdd9e96a134be0ee529aa
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 1ff961dd6d51247e82e41de052f04fd0b577f09b |
|
17-Apr-2015 |
John Reck <jreck@google.com> |
Revert "Remove Bitmap#getSkBitmap"
This reverts commit 4bd981ec533a65e8dee053a0a709b484770b0a76.
Change-Id: I5c92cd955c6e70e197dc5cbc5dfeed8369a24a31
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 4bd981ec533a65e8dee053a0a709b484770b0a76 |
|
16-Apr-2015 |
John Reck <jreck@google.com> |
Remove Bitmap#getSkBitmap
Change-Id: Ifb9047b426122d3e5a445eb7a0eb3fce38dedf27
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 87ffb63d90fb6dd2689fe72dcb24fda9a6156220 |
|
15-Apr-2015 |
John Reck <jreck@google.com> |
Move AssetAtlas off of SkBitmap*
Switched to SkPixelRef*
Change-Id: I4a1d9dc6c55c1ebcce6b0b8c585e69559e523898
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 1c2bf03d1082fc6b7eb42cbd163c60c07cf2bccc |
|
02-Mar-2015 |
Tor Norbye <tnorbye@google.com> |
Annotate return values with @CheckReturn
Change-Id: Icd8fb6adb591ccd7f35f2336ae716b198abf69c5
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 80756e38882720860db52f1fcc21fa1505a02abf |
|
02-Mar-2015 |
Tor Norbye <tnorbye@google.com> |
Annotate ARGB integer parameters with @ColorInt
Change-Id: I307f72a382272cf18ddb6b07d9fcb81228568d9a
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| f4faeac3525fe1ce3707ab785a1651aec367589d |
|
05-Mar-2015 |
John Reck <jreck@google.com> |
Cleanup Bitmap JNI attempt #2
Original version missed a spot
This reverts commit c02977e3bbfaaedcb1b1d67e1692becc7dddd59b.
Change-Id: I56244ce10d709fcdef42a001fe4c6ba7b6bbb04d
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| c02977e3bbfaaedcb1b1d67e1692becc7dddd59b |
|
05-Mar-2015 |
Chad Jones <chadj@google.com> |
Revert "Cleanup Bitmap JNI"
This reverts commit b2915245b74b3b5541b123e38403f8e26426b4b7.
Change-Id: Idd7d7f33eec4ea5024c83de6b10d3d1a6ab2b17a
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| b2915245b74b3b5541b123e38403f8e26426b4b7 |
|
04-Mar-2015 |
John Reck <jreck@google.com> |
Cleanup Bitmap JNI
Fix a bunch of places where mNativeBitmap was being
poked at directly, switch them either to the NDK API
or to GraphicsJNI where it made sense
Change-Id: I6b3df3712d6497cba828c2d3012e725cb4ebb64d
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| fe026218d0e2d122905b990cbb074771325424bb |
|
23-Jan-2015 |
John Reck <jreck@google.com> |
am 94474515: Merge "Prevent memory corruption from use-after-free" into lmp-mr1-dev automerge: bb8d7ff
automerge: 1e5dd46
* commit '1e5dd46133bd47445ba0657692fb86492acad705':
Prevent memory corruption from use-after-free
|
| 4018eb376383a9bbe2aa75a95cc6917ca72aa0b7 |
|
23-Jan-2015 |
John Reck <jreck@google.com> |
Prevent memory corruption from use-after-free
Bug: 19035637
If an app tries to call recycle() on a Bitmap that has
already been finalized it will result in use-after-frees. This is
bad. Avoid this by setting the pointer to 0 and checking for this
Change-Id: I12d73703a0f95b05fe4c2fd8e9c01b6a3f2f023b
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 1022888d33c82dedb3ab3a53d1c3bb432eca93f7 |
|
05-Dec-2014 |
John Reck <jreck@google.com> |
resolved conflicts for merge of 203c8171 to master
Change-Id: I256397410c261fae049bae4572f132235be1c5c9
|
| f29d5a5b211786248d0557157c304c5fff428bd4 |
|
03-Dec-2014 |
Derek Sollenberger <djsollen@google.com> |
Update AndroidPixelRef to prevent VM from cleaning up memory prematurely.
bug:18306529
Change-Id: I1ea94df1dcaf4fcf248b63dc8b0a13f36412570a
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| dfba4d3d11bbf47dff45f94d61d4d97510b3034a |
|
02-Sep-2014 |
Derek Sollenberger <djsollen@google.com> |
Mutable Java Shaders with Immutable Native Shaders
bug: 17641888
Change-Id: I0f05387423cde185dab1a1453f89d5251ca1a4f9
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 4cd7dbc90f93893f521dce32d8cd25c02a185a24 |
|
26-Aug-2014 |
Chris Craik <ccraik@google.com> |
Notify VM of native pixelref allocations
bug:17178931
Change-Id: I0de22bb0d2ae8233d392b7e222f72391aaa12ce8
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 0df3bd5594bbbbfbf6058ecb31e9b94a1cd22f7d |
|
05-Aug-2014 |
John Reck <jreck@google.com> |
Add Bitmap.compress to TRACE_TAG_RESOURCES
Bug: 16800719
TRACE_TAG_RESOURCES shows bitmap decoding, have it show
compressing as well
Change-Id: I04f62545be52698de5371a2594973fa336e7b2fa
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 47cd8e921db73e894f94ec4729ade90da50996f5 |
|
09-Jul-2014 |
Chris Craik <ccraik@google.com> |
Implement outline support for nine patches
b/15856895
Nine patches now have outline round rect metadata stored as optional
png tags. aapt generates these automatically by inspecting the bitmap
pixels to estimate outline bounds and round rect radius, based on
opacity.
Change-Id: I226e328a97873010d9e1adb797ac48f93a31183c
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| c054966b719c8a7255f7cf4120cca5050acb68bd |
|
04-Jul-2014 |
Alan Viverette <alanv@google.com> |
Make optical insets actually work
Change-Id: I9fabf4cb939cc7a868f95580e7229745acde0418
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 57ee620ced8caed1eb8651717f6a6d2d5f1f9a5b |
|
05-Jun-2014 |
Leon Scroggins III <scroggo@google.com> |
Read premultiplied status from the SkBitmap.
Replace the Java variable with mRequestPremultiplied, to better
reflect what it represents. In both native and Java, the SkBitmap
is used as the decision maker of whether a Bitmap is premultiplied.
When changing other settings, mRequestedPremultiplied is used to
determine whether it should be premultiplied (if the new config/
hasAlpha-ness etc supports it).
ChooseFromColorProc now reads both the colortype (instead of the
deprecated Config) and alphatype on the SkBitmap. Same with
ChooseToColorProc. In the process, this caught a bug, where the
wrong procs were being used for Index8.
Replace instances of SkBitmap::Config with SkColorType where I
was already changing code.
Use the new versions of setConfig/allocPixels that take an SkImageInfo
as a parameter.
Document isPremultiplied's return value for ALPHA_8.
BUG:13618134
Change-Id: I91fc1f1e46e9294364b1af0ab4bdb37c68d7058e
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 17a8bfc38a565ae96f43d36b223779be840bb50c |
|
03-Jun-2014 |
Leon Scroggins III <scroggo@google.com> |
In Bitmap.reconfigure, update the pixelref's info.
This fixes CTS tests which are crashing on an SkASSERT due to a
mismatch of SkImageInfo between the SkPixelRef and SkBitmap.
Also directly call ref() and unref() instead of SkSafeRef/SkSafeUnref,
since we would already crash if the SkPixelRef in question was NULL.
Also if the user attempts to reconfigure to 4444, use 8888 instead.
Change-Id: I473ef225c6cd1c92d67ae103c53c6cff0dad92de
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 1e1f4d705edaad3700b49c730bc8a22c522cb46b |
|
24-Mar-2014 |
John Reck <jreck@google.com> |
am 02e99e27: am ae316643: am aff40e25: am fc603ca6: am abf701e6: Merge "Eliminate mHasAlpha" into klp-dev
* commit '02e99e272dbfedf5d9ba1ae91fa2b83cab5b3d07':
Eliminate mHasAlpha
|
| aff40e25e8f16c3ecd20376901d7062774850023 |
|
21-Mar-2014 |
John Reck <jreck@google.com> |
am fc603ca6: am abf701e6: Merge "Eliminate mHasAlpha" into klp-dev
* commit 'fc603ca6b518777a7e4dc391bc771e5609ab3ab5':
Eliminate mHasAlpha
|
| fc603ca6b518777a7e4dc391bc771e5609ab3ab5 |
|
21-Mar-2014 |
John Reck <jreck@google.com> |
am abf701e6: Merge "Eliminate mHasAlpha" into klp-dev
* commit 'abf701e6751aed487d4ed0986e0fae8810c3658f':
Eliminate mHasAlpha
|
| 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
|
| c4c484c6a77b6b88030f1cb7e810918d8ad92146 |
|
18-Mar-2014 |
Ben Murdoch <benm@google.com> |
am e9529bc4: am d292aac5: am 889a1ddd: Fix JavaDoc
* commit 'e9529bc4cb28176fddf1e7916c7791e5974f2fc3':
Fix JavaDoc
|
| f168e4c46cf8102263b7c92807d35b19d827339a |
|
18-Mar-2014 |
Doug Zongker <dougz@android.com> |
resolved conflicts for merge of a1ca303a to master
Change-Id: I37ef6102fd79e396fa3e50d6c012a667488a306d
|
| 889a1ddd00b74933d5f7daa651d98133bcb034ba |
|
17-Mar-2014 |
Ben Murdoch <benm@google.com> |
Fix JavaDoc
Change-Id: I20d0b1544ba88c694b950ef6062f93c65b16d371
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 5aa9c5a77ba498108f7395df1865ee34eacebf49 |
|
17-Mar-2014 |
Torne (Richard Coles) <torne@google.com> |
Fix javadoc.
Fix javadoc reference missing a #
Bug: 13246311
Change-Id: Ifc06234943339250feb5b4f2077af03c35be076e
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| f8d8777dddf91c741981b4f795f2fb2b1d81c1b6 |
|
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
Conflicts:
core/jni/android/graphics/Bitmap.cpp
core/jni/android/graphics/Graphics.cpp
core/jni/android/graphics/Typeface.cpp
graphics/java/android/graphics/Bitmap.java
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 87e9e744ed7acc554a6b4c7dd90fab376eabb30b |
|
06-Mar-2014 |
Leon Scroggins III <scroggo@google.com> |
am 92a32832: DO NOT MERGE - Fix Javadoc build break.
* commit '92a3283286df3a6c2a27ecde8eddf23abbb87de9':
DO NOT MERGE - Fix Javadoc build break.
|
| 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
|
| 8d3281f5f7a880b996e50d291ebb7154a486eb6c |
|
06-Mar-2014 |
Leon Scroggins III <scroggo@google.com> |
am ee008d42: Merge "Update framework to use M33 Skia. DO NOT MERGE" into klp-dev
* commit 'ee008d4264a95bba5f90b17856fc06fa29a6f12c':
Update framework to use M33 Skia. DO NOT MERGE
|
| 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
|
| b644a3b84521e2155a5af985a4d4ed305474e567 |
|
17-Jan-2014 |
Derek Sollenberger <djsollen@google.com> |
Updates to the Skia API needed to merge the WebView m33 version of Skia.
This is a cherry-pick of 2 CLs:
21969a2b26945da3fd86aef7c93479e4fb359a65
c7a581cf7691db5c61e6694aa51daaa994004bd9
Change-Id: I6fd9366fbba0a336de1df794be9497983bfd13ae
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| a0398430fcf365fba6e42ad0bdca2fbf45ed6fe0 |
|
20-Jan-2014 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Make graphics classes 64-bit compatible
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Change-Id: I940433f601c6db998c1a8ffff338f5361200d5ed
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 36bef0bf30d6bae48cf3837df351075ca4fce654 |
|
20-Jan-2014 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Make graphics classes 64-bit compatible
This a merger of two commits submitted to AOSP by
the following authors:
ashok.bhat@arm.com, david.butcher@arm.coma
craig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com
Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.
Commit messages below:
================================================
AArch64: Make graphics classes 64-bit compatible
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
==================================================================
AArch64: Use long for pointers in graphics/Camera
For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
===================================================================
Change-Id: Id5793fa0ebc17ee8b1eecf4b3f327977fdccff71
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 7023df08f14ec5dee76ac54c03e870f84e297636 |
|
27-Jan-2014 |
Narayan Kamath <narayan@google.com> |
Revert "AArch64: Make graphics classes 64-bit compatible"
This reverts commit 18b4cbeedef21c1fa666a110a157bab66edff976.
Change-Id: I0c52983a3ab1ace3ff743de546a43eca28e5cb0e
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 18b4cbeedef21c1fa666a110a157bab66edff976 |
|
20-Jan-2014 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Make graphics classes 64-bit compatible
This a merger of two commits submitted to AOSP by
the following authors:
ashok.bhat@arm.com, david.butcher@arm.coma
craig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com
Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.
Commit messages below:
================================================
AArch64: Make graphics classes 64-bit compatible
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
==================================================================
AArch64: Use long for pointers in graphics/Camera
For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
===================================================================
Change-Id: Ib3eab85ed97ea3e3c227617c20f8d213f17d4ba0
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 2bc49ca96eb786f66dc2b9573e1f09bdb2d82d5e |
|
15-Jan-2014 |
Leon Scroggins III <scroggo@google.com> |
Fix Javadoc build break.
Remove links to non-specific function name.
Change-Id: I5643074149d0a511bd760d638751c44e3ec4c557
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| 8790be6de3644e332ec6a17c855da89ffc13a9bf |
|
03-Dec-2013 |
Leon Scroggins III <scroggo@google.com> |
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.
Change-Id: I1b36b0b0ce7126031eb7b769b563c17dcd4b306a
/frameworks/base/graphics/java/android/graphics/Bitmap.java
|
| badb59cd5d2a2905494964889f002a277211000a |
|
07-Nov-2013 |
Newton Allen <newt@google.com> |
am 47feee53: Merge "Fix some documentation typos." into klp-docs
* commit '47feee535f9e4e77165b93b6b9f10379e7aa4bbd':
Fix some documentation typos.
|
| 4899398dcad50d1b9734ca5f8959712f42f72b02 |
|
07-Nov-2013 |
Chris Craik <ccraik@google.com> |
am baba771c: am 47742d4b: Merge "Fix NPE with inPurgeable Bitmaps in getAllocationByteCount" into klp-dev
* commit 'baba771c85ec4a8d56e07c0d963c663a99cfa0e3':
Fix NPE with inPurgeable Bitmaps in getAllocationByteCount
|
| 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
|
| ff236f5fc1a088b1210d37a67b0e88b06c0fbdb2 |
|
13-Aug-2013 |
Newton Allen <newt@google.com> |
Fix some documentation typos.
Change-Id: I0360d468d54d970c87f313e24e50965245206f28
(cherry picked from commit c502744f2ddcc80a34f5197b5d2c0d701c7d6e71)
/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
|