cc: Use gather pixel refs with positions util.

cc: Use gather pixel refs with positions util.

This is part 2 of patch: actually using the pixel refs with positions.
I'm still storing the pixel refs in a grid, but this reduces the number
of walks. This still keeps the impl thread quick, and improves the
record time.

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

[vmpstr, 2013-05-31 20:52:51]

PTAL. This depends on https://codereview.chromium.org/15732015/

I just did some informal stats with traces on theverge:
Before patch:
Record time 14.2ms (1633.4ms over 115 pictures)
Gather time 3.05ms (351.7ms over 115 pictures)

After patch:
Record time 12.75ms (1415.339 over 111 pictures)
Gather time 0.58ms (64.925 over 111 pictures)

[enne (OOO), 2013-05-31 21:06:24]

How many images per picture are there? Do you think the grid is worth keeping?

[vmpstr, 2013-05-31 21:55:15]

On 2013/05/31 21:06:24, enne wrote:
> How many images per picture are there? Do you think the grid is worth keeping?

On the verge, the total number (on pictures that have lazy pixel refs) is about
20-60. When they get put in the cells, each cell has about 1-6 pixel refs. If we
have about 4 grid cells per tile (for high res tiles), then I think it's still
worth it.

I'm just weary about really long page with a lot of the pixel refs. Then for
each tile, we'd have to iterate all of those to see if it intersects. Wdyt?

[enne (OOO), 2013-05-31 22:47:29]

lgtm, with one question:

https://codereview.chromium.org/16154008/diff/1/cc/resources/picture.cc
File cc/resources/picture.cc (right):

https://codereview.chromium.org/16154008/diff/1/cc/resources/picture.cc#newco...
cc/resources/picture.cc:285:
RoundDown(static_cast<int>(it->pixel_ref_rect.right()) + 1,
Do you mean RoundUp here?

[vmpstr, 2013-05-31 23:08:46]

On 2013/05/31 22:47:29, enne wrote:
> lgtm, with one question:
> 
> https://codereview.chromium.org/16154008/diff/1/cc/resources/picture.cc
> File cc/resources/picture.cc (right):
> 
>
https://codereview.chromium.org/16154008/diff/1/cc/resources/picture.cc#newco...
> cc/resources/picture.cc:285:
> RoundDown(static_cast<int>(it->pixel_ref_rect.right()) + 1,
> Do you mean RoundUp here?

No, this should be RoundDown. The pixel refs for a rect x,y width x height are
stored in x y.. If we RoundUp then that pixel ref will be stored in a wrong
cell, I think. I think I might not need the +1, but that was to make sure the
resulting width/height is at least as big as the initial one (ie because I
truncate to int)

[enne (OOO), 2013-05-31 23:10:59]

On 2013/05/31 23:08:46, vmpstr wrote:
> On 2013/05/31 22:47:29, enne wrote:
> > lgtm, with one question:
> > 
> > https://codereview.chromium.org/16154008/diff/1/cc/resources/picture.cc
> > File cc/resources/picture.cc (right):
> > 
> >
>
https://codereview.chromium.org/16154008/diff/1/cc/resources/picture.cc#newco...
> > cc/resources/picture.cc:285:
> > RoundDown(static_cast<int>(it->pixel_ref_rect.right()) + 1,
> > Do you mean RoundUp here?
> 
> No, this should be RoundDown. The pixel refs for a rect x,y width x height are
> stored in x y.. If we RoundUp then that pixel ref will be stored in a wrong
> cell, I think. I think I might not need the +1, but that was to make sure the
> resulting width/height is at least as big as the initial one (ie because I
> truncate to int)

Ah, ok.  Then maybe use std::ceil() instead of adding one?

[vmpstr, 2013-05-31 23:14:02]

On 2013/05/31 23:10:59, enne wrote:
> On 2013/05/31 23:08:46, vmpstr wrote:
> > On 2013/05/31 22:47:29, enne wrote:
> > > lgtm, with one question:
> > > 
> > > https://codereview.chromium.org/16154008/diff/1/cc/resources/picture.cc
> > > File cc/resources/picture.cc (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/16154008/diff/1/cc/resources/picture.cc#newco...
> > > cc/resources/picture.cc:285:
> > > RoundDown(static_cast<int>(it->pixel_ref_rect.right()) + 1,
> > > Do you mean RoundUp here?
> > 
> > No, this should be RoundDown. The pixel refs for a rect x,y width x height
are
> > stored in x y.. If we RoundUp then that pixel ref will be stored in a wrong
> > cell, I think. I think I might not need the +1, but that was to make sure
the
> > resulting width/height is at least as big as the initial one (ie because I
> > truncate to int)
> 
> Ah, ok.  Then maybe use std::ceil() instead of adding one?

That's a good point :)

[commit-bot: I haz the power, 2013-06-03 15:35:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vmpstr@chromium.org/16154008/10001

[commit-bot: I haz the power, 2013-06-04 03:58:42]

Change committed as 203836