Android: limit image decoded size based on amount of physical memory

Android: limit image decoded size based on amount of physical memory

The previous change (https://codereview.chromium.org/23600067/) added
limit for low end devices (memory <= 512MB). Now limit on all devices
to display huge images without crash or displaying as corrupted images.

This CL is still Android. The method might be also useful on other
platforms but the best parameters may differ (may be affected by the
swap memory).

BUG=303848
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=227063

[Xianzhu, 2013-10-03 21:49:42]

Grace, do you think we could use the same expression for all devices? e.g.
physicalMemory / 16:

physical  limit
256MB    4M pixels  (original 3M pixels)
512MB    8M pixels  (original 3M pixels)
1GB         16M pixels
2GB         32M pixels

I think when memory allows, we should set the limit as high as possible. Though
the image may be much larger than the screen, sometimes the user want to see the
details by zooming in and panning them. Examples include the picturized long
blogs on weibo.com, and the huge global images from NASA.

Had considered using availablePhysicalMemory, but it is too small and seems not
a good base to calculate the image size limit. For example, for a 1G memory
Nexus 7 newly rebooted and idled for several minutes, availablePhysicalMemory is
only 50MB.

[klobag.chromium, 2013-10-04 04:28:44]

On 2013/10/03 21:49:42, Xianzhu wrote:
> Grace, do you think we could use the same expression for all devices? e.g.
> physicalMemory / 16:
> 
> physical  limit
> 256MB    4M pixels  (original 3M pixels)
> 512MB    8M pixels  (original 3M pixels)
> 1GB         16M pixels
> 2GB         32M pixels
> 
> I think when memory allows, we should set the limit as high as possible.
Though
> the image may be much larger than the screen, sometimes the user want to see
the
> details by zooming in and panning them. Examples include the picturized long
> blogs on http://weibo.com, and the huge global images from NASA.
> 
> Had considered using availablePhysicalMemory, but it is too small and seems
not
> a good base to calculate the image size limit. For example, for a 1G memory
> Nexus 7 newly rebooted and idled for several minutes, availablePhysicalMemory
is
> only 50MB.

[klobag.chromium, 2013-10-04 04:31:40]

On 2013/10/04 04:28:44, klobag.chromium wrote:
> On 2013/10/03 21:49:42, Xianzhu wrote:
> > Grace, do you think we could use the same expression for all devices? e.g.
> > physicalMemory / 16:
> > 
> > physical  limit
> > 256MB    4M pixels  (original 3M pixels)
> > 512MB    8M pixels  (original 3M pixels)
> > 1GB         16M pixels
> > 2GB         32M pixels
> > 
> > I think when memory allows, we should set the limit as high as possible.
> Though
> > the image may be much larger than the screen, sometimes the user want to see
> the
> > details by zooming in and panning them. Examples include the picturized long
> > blogs on http://weibo.com, and the huge global images from NASA.
> > 
> > Had considered using availablePhysicalMemory, but it is too small and seems
> not
> > a good base to calculate the image size limit. For example, for a 1G memory
> > Nexus 7 newly rebooted and idled for several minutes,
availablePhysicalMemory
> is
> > only 50MB.

I don't think it should be linear. For low end device, we need to be aggressive
to limit the size. e.g. the flower example in image.google.com is around 8M,
which caused the renderer crash.

[klobag.chromium, 2013-10-04 04:33:30]

lgtm

[tony, 2013-10-04 16:18:32]

LGTM2, would be nice to have some unit tests for this.

[Xianzhu, 2013-10-04 17:01:35]

On 2013/10/04 16:18:32, tony wrote:
> LGTM2, would be nice to have some unit tests for this.

In blink we have unit tests to test how JPEGImageDecoder honor maxDecodedSize.
Dedicated unit test for this change seems unnecessary because it would just
repeat the same algorithm of the tested function. Also it seems not feasible to
mock SysInfo::AmountOfPhysicalMemory().

[commit-bot: I haz the power, 2013-10-04 17:12:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wangxianzhu@chromium.org/25938002/8001

[commit-bot: I haz the power, 2013-10-04 19:58:41]

Change committed as 227063