| Age | Commit message (Collapse) | Author |
|---|
|
Bug: 183115528
Test: (A)ImageDecoderTest(s) (verify correctness)
Test: monitor showmap_pss_bytes dashboards (verify memory impact)
This lets the decoder leave zero initialized memory untouched. An
Android feature makes untouched zero initialized memory cheaper, and
BitmapFactory takes advantage of it. Do the same for ImageDecoder.
This feature was originally brought up in b/10016979. ImageDecoder saved
memory in other ways, and as I understand it, Android has shifted
towards using (Animated)VectorDrawables. Both of these may have
contributed to us not noticing when we switched from BitmapFactory to
ImageDecoder.
Change-Id: Iecfd1bbfdcc38e1f0bf380b4f4ea5b861cfcf08a
|
|
Test: I138ec784a77253c7ae94765d0670e5947d97caf5
Recently (Ib93b0ced09fa3cca4a6681745406355c48158fae), handling exif
moved from SkAndroidCodec to hwui/ImageDecoder. This missed
getSampledDimensions, which reports the sampled dimensions without
taking exif into account. Fix this for both
android.graphics.ImageDecoder and AImageDecoder. Note that in the Java
case, the method is private, and although the method was returning
swapped dimensions in some cases, it gets corrected by
getTargetDimension, so there is no user visible change.
Change-Id: I918328c39d6230ae6ba4cab0733fff0732b39888
|
|
Bug: 160984428
Test: AImageDecoderTest#testRespectOrientation
ImageDecoderTest#testRespectOrientation
Ieda439910ae52e609f0710d424503616d99ae5c7
I23caef26b4c82173c758dd0ce7fb6f04e4154588
I345a13d20776a007052d32e74fa42865b42f726d
It is possible to create an animated image with an exif orientation.
Using kRespect, there is no clean way to handle the orientation plus
compositing frames. Switch ImageDecoder to use kIgnore (the default).
Depends on a change in Skia (https://review.skia.org/344762) to make
SkAnimatedImage handle the orientation even with kIgnore.
Change-Id: Ib93b0ced09fa3cca4a6681745406355c48158fae
|
|
Bug: 166069819
Test: ImageDecoderTest (cts)
The contained asset may only be a subset of the AssetFileDescriptor.
SkWebpCodec reads the entire stream into a contiguous block of memory.
(This is because libwebp does not provide a streaming API for creating
its demuxer.) If the AssetFileDescriptor contains data after the webp
file, this wastes memory. In some cases, there may be a *lot* of data
after the webp file, so this can use too much memory, particularly on
low memory devices.
Change-Id: I8d8e520f43a7ef0d7e4534ef165d8c7e4d2a0b55
|
|
Bug: skbug.com/10154
Test: CtsGraphicsTestCases
The API is being moved to a new file and renamed. Use the new API.
Remove an unncessary FIXME and comment in Movie.cpp. The hardcoded 6 is
fine, and the ownership is obvious now that we use smart pointers.
Change-Id: I79657626ccbd5fe2616d546c617d591928064106
|
|
Bug: 153071768
Test: AImageDecoderTest
For simplicity, I1aff544e8d6932b9ed0931a00da66a0aba6cd536 made
ImageDecoder skip specifying kOpaque when setting the SkImageInfo for
decoding. For some formats (e.g. jpeg and heif), this results in a log
message:
"Warning: an opaque image should be decoded as opaque - it is being
decoded as non-opaque, which will draw slower"
This isn't relevant to AImageDecoder, which doesn't let you specify
kOpaque or not (since the intent is not to create an SkBitmap for Skia).
Now that ImageDecoder specifies kOpaque properly, the JNI code no longer
needs to correct it.
Replace another opacity check with ::opaque() for simplicity.
Change-Id: I7c270d9b9db61a61a338f40b056ce5d23a56e14d
|
|
This includes AndroidRuntime and core_jni_helper.h
Bug: 137655431
Test: CtsUiRenderingTestCases
Change-Id: If3d26f41eaf4981505ee47634097f3645fd563fd
|
|
The graphics JNI code is now separate from libandroid_runtime
and it along with HWUI headers are no longer visible to targets
outside the boundary of what is to become the UI mainline module
The exposed headers to targets outside the module are now restriced
to C APIs contained in the apex header directory.
Bug: 137655431
Test: CtsUiRenderingTestCases
Change-Id: I30d34055b6870dc1039f190a88f4a747cee17300
|
