WAI
Status Update
Comments
vi...@google.com <vi...@google.com>
vi...@google.com <vi...@google.com> #2
We have passed this to the development team and will update this issue with more information as it becomes available.
vi...@google.com <vi...@google.com> #3
Please find the below response received from our engineering team:
"> - All would be on native memory instead of heap, to avoid OOM
Bitmaps are intended to count against the Java heap. It is important to manage memory to stay within reasonable usage for mobile devices.
> - allow direct decoding into specific resolution, cropping if needed.
ImageDecoder on P allows scaling (setTargetSize) and cropping (setCrop)
> - handling exif rotation in all forms, including correct, direct decoding or region decoding. This should include ImageView that can handle it
ImageDecoder on P handles all eight exif rotation options. ImageView does not need to do any extra work.
> - library that should be supported from API 14.
We are planning a Support Library for ImageDecoder"
"> - All would be on native memory instead of heap, to avoid OOM
Bitmaps are intended to count against the Java heap. It is important to manage memory to stay within reasonable usage for mobile devices.
> - allow direct decoding into specific resolution, cropping if needed.
ImageDecoder on P allows scaling (setTargetSize) and cropping (setCrop)
> - handling exif rotation in all forms, including correct, direct decoding or region decoding. This should include ImageView that can handle it
ImageDecoder on P handles all eight exif rotation options. ImageView does not need to do any extra work.
> - library that should be supported from API 14.
We are planning a Support Library for ImageDecoder"
lb...@gmail.com <lb...@gmail.com> #4
@3
"Bitmaps are intended to count against the Java heap. It is important to manage memory to stay within reasonable usage for mobile devices."
This is incorrect on Android 8.0 and above. They are stored on the native memory instead, and can't cause OOM at all. If you run out of memory you will get a different error instead which I don't think you can catch. I wrote about this here:
https://stackoverflow.com/q/48091403/878126
This is actually almost the best thing that can be, as we can feel more free about using Bitmaps. Sadly this isn't this way on older Android versions, which is why I requested it here as one of the points.
"ImageDecoder on P allows scaling (setTargetSize) and cropping (setCrop)"
"ImageDecoder on P handles all eight exif rotation options. ImageView does not need to do any extra work."
The request is to offer a library for all Android versions. ImageDecoder is currently available on Android P.
Could be nice if you allow to use it on older Android versions, of course.
"We are planning a Support Library for ImageDecoder"
This is great news.
In order to make it work for all Android versions, it's important that the Bitmap operations would be in native memory, to avoid possible OOM on older Android versions.
I wonder though:
Does the new API have cache mechanism? Maybe even something that's global to the OS, in case of accessing URLs ?
If it has some cache mechanism, is it memory safe, meaning we don't need to worry about its size and we don't need to specify how much memory it will take?
Same goes for disk-cache.
"Bitmaps are intended to count against the Java heap. It is important to manage memory to stay within reasonable usage for mobile devices."
This is incorrect on Android 8.0 and above. They are stored on the native memory instead, and can't cause OOM at all. If you run out of memory you will get a different error instead which I don't think you can catch. I wrote about this here:
This is actually almost the best thing that can be, as we can feel more free about using Bitmaps. Sadly this isn't this way on older Android versions, which is why I requested it here as one of the points.
"ImageDecoder on P allows scaling (setTargetSize) and cropping (setCrop)"
"ImageDecoder on P handles all eight exif rotation options. ImageView does not need to do any extra work."
The request is to offer a library for all Android versions. ImageDecoder is currently available on Android P.
Could be nice if you allow to use it on older Android versions, of course.
"We are planning a Support Library for ImageDecoder"
This is great news.
In order to make it work for all Android versions, it's important that the Bitmap operations would be in native memory, to avoid possible OOM on older Android versions.
I wonder though:
Does the new API have cache mechanism? Maybe even something that's global to the OS, in case of accessing URLs ?
If it has some cache mechanism, is it memory safe, meaning we don't need to worry about its size and we don't need to specify how much memory it will take?
Same goes for disk-cache.
ey...@gmail.com <ey...@gmail.com> #5
Is it safe to assume that there isn't going to be an ImageDecoder android library?
vi...@google.com <vi...@google.com> #6
Please find the below responses:
- All would be on native memory instead of heap, to avoid OOM
Bitmaps are intended to count against the Java heap. It is important to manage memory to stay within reasonable usage for mobile devices.
- allow direct decoding into specific resolution, cropping if needed.
ImageDecoder on P allows scaling (setTargetSize) and cropping (setCrop)
- handling exif rotation in all forms, including correct, direct decoding or region decoding. This should include ImageView that can handle it
ImageDecoder on P handles all eight exif rotation options. ImageView does not need to do any extra work.
- library that should be supported from API 14.
We are planning a Support Library for ImageDecoder
sc...@google.com <sc...@google.com> #7
We are planning a Support Library for ImageDecoder
Sorry, that comment is out of date. We now recommend using a 3p library like Glide or Picasso.
Description
- All would be on native memory instead of heap, to avoid OOM
- library that should be supported from API 14.
- allow direct decoding into specific resolution, cropping if needed.
- handling exif rotation in all forms, including correct, direct decoding or region decoding. This should include ImageView that can handle it