Track positions of dimensions in image files

Track positions of dimensions in image files

Records how much of an image file must be retrieved in
bytes to decode the image dimensions with the current
implementation and with an optimized implementation.

BUG=582486

[bengr, 2016-01-30 00:39:35]

bengr@chromium.org changed reviewers:
+ asvitkine@google.com, schenney@chromium.org

[bengr, 2016-01-30 00:39:36]

PTAL

[bengr, 2016-01-30 00:42:19]

bengr@chromium.org changed reviewers:
+ noel@chromium.org
- schenney@chromium.org

[bengr, 2016-01-30 00:42:19]

PTAL.

[Alexei Svitkine (slow), 2016-02-01 20:51:11]

asvitkine@chromium.org changed reviewers:
+ asvitkine@chromium.org

[Alexei Svitkine (slow), 2016-02-01 20:51:11]

https://codereview.chromium.org/1647703006/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/image-decoders/gif/GIFImageDecoder.cpp
(right):

https://codereview.chromium.org/1647703006/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/image-decoders/gif/GIFImageDecoder.cpp:340:
"Blink.Images.SizeOffsetOptimized_GIF", m_sizeOffsetOptimized, 1, 1000000, 50);
If you prefer, you can use . instead of _ and specify separator="." in the xml.

https://codereview.chromium.org/1647703006/diff/20001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1647703006/diff/20001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:3094: +<histogram
name="Blink.Images.SizeOffset">
Please add units="" to these.

[Noel Gordon, 2016-03-03 04:11:33]

Note sure what's happening with this CL, or why this is image decoder change is
needed.

[bengr, 2016-03-07 23:59:14]

On 2016/03/03 04:11:33, noel gordon wrote:
> Note sure what's happening with this CL, or why this is image decoder change
is
> needed.

Thanks, Noel. I might close this out, or reduce the scope. Please hold off on
reviewing.

We are considering issuing range requests when layout needs dimensions and the
image itself isn't needed. The CL would determine how many bytes into the files
we'd have to read in practice to retrieve the dimensions. The GIF decoder was
instrumented to see how often the first frame adjusts the dimensions in
practice, while the JPEG decoder was instrumented to see how far into the header
we'd need to read to get dimensions.

[Noel Gordon, 2016-03-08 12:52:09]

On 2016/03/07 23:59:14, bengr wrote:
> On 2016/03/03 04:11:33, noel gordon wrote:
> > Note sure what's happening with this CL, or why this is image decoder change
> is
> > needed.
> 
> Thanks, Noel. I might close this out, or reduce the scope. Please hold off on
> reviewing.

OK, thanks for the FYI.

> We are considering issuing range requests when layout needs dimensions and the
> image itself isn't needed. The CL would determine how many bytes into the
files
> we'd have to read in practice to retrieve the dimensions.

Blink can't layout an image until we have read the image header.  The
ImageDecoder{.h,.cpp} have the concept of isSizeAvailable(), which transitions
from false -> true once sufficient bytes have been received from the network to
read the image header without error.  Once the image size is available, that
means that the header reading is complete and that we know the image width and
height.  Only then do we attempt to layout / paint the image. 

Image headers are variable length, of course.  They are usually small-ish (under
1K) but can be much larger due to things like having an embedded color profile
for example, which are contained in the image header bytes and can be quite
large when decompressed (up to 4Meg), so YMMV for what you are trying to do.