Handling large jpegs in CPU raster - downsample to display res and 565

Handling large jpegs in CPU raster - downsample to display res and 565

Blink decoder implementation, corresponding to this change is in:
crrev.com/1403393004#ps40001

Cacherator gets requested size from SkBaseDevice attempting draw,
if cache contains lower res or if it doesnt contain the resource,
generator is asked about capabilities to decode to rgb565 and downsample
to scale equal or higher than the one needed for display.
generator can answer that scale, colortype or both are available in one call.

Disclaimer:
Initial implementation covers CPU raster only and SkBaseDevice::drawImageRect,
as that place is the only one identified to invoke decoding in related
bug 472630. Once the test for drawImage is identified, implementation
would extend to it. GPU raster planned for later, too.

BUG=chromium:438323, chromium:472630

[aleksandar.stojiljkovic, 2015-10-23 09:01:00]

Description was changed from

==========
Handling large jpegs in CPU raster - downsample to display res and 565

Blink decoder implementation, corresponding to this change is in:
crrev.com/1403393004#ps40001

Cacherator gets requested size from SkBaseDevice attempting draw,
if cache contains lower res or if it doesnt contain the resource,
generator is asked about capabilities to decode to rgb565 and downsample
to scale equal or higher than the one needed for display.
generator can answer that scale, colortype or both are available in one call.

Disclaimer:
Initial implementation covers CPU raster only and SkBaseDevice::drawImageRect,
as that place is the only one identified to invoke decoding in related
bug 472630. Once the test for drawImage is identified, implementation
would extend to it. GPU raster planned for later, too.

BUG=chromium:438323, chromium:472630

Decode and display images in display resolution

Addresses: Chromium issues 438323, 472630:
Multiple large (~2800x2000) jpegs on page evict each other from discardable
cache and
  severely deteriorate performance
Expensive

This is a prototype code intended for verifying the approach. If approach gets
LGTM, following patches are planned:
1. remove intermediate full size bitmap from bool
SkImageCacherator::generateBitmap
   instead, enable decoding to scaled down in decoder
2. do it for GPU rasterizing too
3. approach potentially misuses empty bitmap's SkImageInfo to pass hint to
decoder invoked within call to
   getROPixels

Approach drawback:
On pinch zoom, there is something like "CSI zoom" effect; while zooming quickly,
image gets blurry and then
when stopping the zoom image gets cristal clear. Doesn't look that bad dough.
No drawback when doing doubleclick zoom.
==========

to

==========
Handling large jpegs in CPU raster - downsample to display res and 565

Blink decoder implementation, corresponding to this change is in:
crrev.com/1403393004#ps40001

Cacherator gets requested size from SkBaseDevice attempting draw,
if cache contains lower res or if it doesnt contain the resource,
generator is asked about capabilities to decode to rgb565 and downsample
to scale equal or higher than the one needed for display.
generator can answer that scale, colortype or both are available in one call.

Disclaimer:
Initial implementation covers CPU raster only and SkBaseDevice::drawImageRect,
as that place is the only one identified to invoke decoding in related
bug 472630. Once the test for drawImage is identified, implementation
would extend to it. GPU raster planned for later, too.

BUG=chromium:438323, chromium:472630

Decode and display images in display resolution

Addresses: Chromium issues 438323, 472630:
Multiple large (~2800x2000) jpegs on page evict each other from discardable
cache and
  severely deteriorate performance
Expensive

This is a prototype code intended for verifying the approach. If approach gets
LGTM, following patches are planned:
1. remove intermediate full size bitmap from bool
SkImageCacherator::generateBitmap
   instead, enable decoding to scaled down in decoder
2. do it for GPU rasterizing too
3. approach potentially misuses empty bitmap's SkImageInfo to pass hint to
decoder invoked within call to
   getROPixels

Approach drawback:
On pinch zoom, there is something like "CSI zoom" effect; while zooming quickly,
image gets blurry and then
when stopping the zoom image gets cristal clear. Doesn't look that bad dough.
No drawback when doing doubleclick zoom.
==========

[aleksandar.stojiljkovic, 2015-10-23 09:01:01]

aleksandar.stojiljkovic@intel.com changed reviewers:
+ reed@google.com

[aleksandar.stojiljkovic, 2015-10-23 09:07:17]

I continued with work proposed in prototype:
Issue 1395593004 Decode and render images in display resolution.
It includes RGB565 and downsampling in jpeg image decoder
(https://codereview.chromium.org/1403393004/)
Will try to close 1395593004 as obsolete.

Thanks.

[aleksandar.stojiljkovic, 2015-10-23 09:08:51]

Description was changed from

==========
Handling large jpegs in CPU raster - downsample to display res and 565

Blink decoder implementation, corresponding to this change is in:
crrev.com/1403393004#ps40001

Cacherator gets requested size from SkBaseDevice attempting draw,
if cache contains lower res or if it doesnt contain the resource,
generator is asked about capabilities to decode to rgb565 and downsample
to scale equal or higher than the one needed for display.
generator can answer that scale, colortype or both are available in one call.

Disclaimer:
Initial implementation covers CPU raster only and SkBaseDevice::drawImageRect,
as that place is the only one identified to invoke decoding in related
bug 472630. Once the test for drawImage is identified, implementation
would extend to it. GPU raster planned for later, too.

BUG=chromium:438323, chromium:472630

Decode and display images in display resolution

Addresses: Chromium issues 438323, 472630:
Multiple large (~2800x2000) jpegs on page evict each other from discardable
cache and
  severely deteriorate performance
Expensive

This is a prototype code intended for verifying the approach. If approach gets
LGTM, following patches are planned:
1. remove intermediate full size bitmap from bool
SkImageCacherator::generateBitmap
   instead, enable decoding to scaled down in decoder
2. do it for GPU rasterizing too
3. approach potentially misuses empty bitmap's SkImageInfo to pass hint to
decoder invoked within call to
   getROPixels

Approach drawback:
On pinch zoom, there is something like "CSI zoom" effect; while zooming quickly,
image gets blurry and then
when stopping the zoom image gets cristal clear. Doesn't look that bad dough.
No drawback when doing doubleclick zoom.
==========

to

==========
Handling large jpegs in CPU raster - downsample to display res and 565

Blink decoder implementation, corresponding to this change is in:
crrev.com/1403393004#ps40001

Cacherator gets requested size from SkBaseDevice attempting draw,
if cache contains lower res or if it doesnt contain the resource,
generator is asked about capabilities to decode to rgb565 and downsample
to scale equal or higher than the one needed for display.
generator can answer that scale, colortype or both are available in one call.

Disclaimer:
Initial implementation covers CPU raster only and SkBaseDevice::drawImageRect,
as that place is the only one identified to invoke decoding in related
bug 472630. Once the test for drawImage is identified, implementation
would extend to it. GPU raster planned for later, too.

BUG=chromium:438323, chromium:472630
==========