Limit image decoded size on low end Android devices

Limit image decoded size on low end Android devices

Limit decoded size to 3M pixels on low end Android devices.
The image decoder may downsample the images to meet the limit.

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

[tony, 2013-09-20 22:27:04]

https://codereview.chromium.org/23600067/diff/1/webkit/child/webkitplatformsu...
File webkit/child/webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/23600067/diff/1/webkit/child/webkitplatformsu...
webkit/child/webkitplatformsupport_impl.cc:892: return 0;  // Unlimited.
Having 0 mean unlimited is a bit weird.  Why not return
numeric_limits<size_t>::max()?

It seems inconsistent that a phone with <= 512mb has a limit, but if a laptop or
desktop has <= 512mb, we continue to decode the image.  Is it worth trying to
scale the image decode size based on memory and/or swap space?

Out of curiosity, are there many phones that can run Chrome (i.e., have Android
OS 4.x) and have <= 512mb of memory?

[Xianzhu, 2013-09-20 23:13:46]

https://codereview.chromium.org/23600067/diff/1/webkit/child/webkitplatformsu...
File webkit/child/webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/23600067/diff/1/webkit/child/webkitplatformsu...
webkit/child/webkitplatformsupport_impl.cc:892: return 0;  // Unlimited.
On 2013/09/20 22:27:04, tony wrote:
> Having 0 mean unlimited is a bit weird.  Why not return
> numeric_limits<size_t>::max()?
> 

Done.

> It seems inconsistent that a phone with <= 512mb has a limit, but if a laptop
or
> desktop has <= 512mb, we continue to decode the image.  Is it worth trying to
> scale the image decode size based on memory and/or swap space?
> 

For now we want to focus on the bug (which is Android-only) and limit this CL to
Android only which will ease the merge process.

[tony, 2013-09-20 23:14:57]

LGTM

https://codereview.chromium.org/23600067/diff/6001/webkit/child/webkitplatfor...
File webkit/child/webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/23600067/diff/6001/webkit/child/webkitplatfor...
webkit/child/webkitplatformsupport_impl.cc:890: return 3 * 1000 * 1000 * 4;  //
4 is maximum number of bytes per pixel.
Nit: Why 1000 instead of 1024?

[Xianzhu, 2013-09-20 23:23:56]

https://codereview.chromium.org/23600067/diff/6001/webkit/child/webkitplatfor...
File webkit/child/webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/23600067/diff/6001/webkit/child/webkitplatfor...
webkit/child/webkitplatformsupport_impl.cc:890: return 3 * 1000 * 1000 * 4;  //
4 is maximum number of bytes per pixel.
On 2013/09/20 23:14:57, tony wrote:
> Nit: Why 1000 instead of 1024?

Just followed the same behavior of iOS browser. Agree that 1024 is better. Done.

[commit-bot: I haz the power, 2013-09-25 17:53:41]

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

[commit-bot: I haz the power, 2013-09-25 19:54:09]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2013-09-25 20:06:27]

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

[commit-bot: I haz the power, 2013-09-25 21:28:29]

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

[commit-bot: I haz the power, 2013-09-26 06:18:13]

Change committed as 225354