Smaller initial DisplayItemList to use less memory.

Smaller initial DisplayItemList to use less memory.

The previous initial size of the DisplayItemList was very pessimistic
and used 10+ KB (64 * sizeof(BeginTransform3DDisplayItem)). On a page like
YouTube there were 50 of them in use so a total of half a MB.

Looking at usage patterns, 512 bytes seems to be enough in many cases
which would save most of that half MB (not all committed so the amount
of reduced RAM usage is in the 1-200 KB range).

BUG=538615
Committed: https://crrev.com/84b2acf3ce32315313f954f956084bbcad83238a
Cr-Commit-Position: refs/heads/master@{#355556}

[Daniel Bratell, 2015-10-21 13:29:19]

bratell@opera.com changed reviewers:
+ jbroman@chromium.org

[Daniel Bratell, 2015-10-21 13:29:20]

jbroman, I think this size reduction works. When I ran some rendering tests
tests a few weeks ago it seemed all changes on the micro benchmarks were within
noise levels (see
http://storage.googleapis.com/chromium-telemetry/html-results/results-2015-10...
from https://codereview.chromium.org/1377353003/ )

Would be good if I could have more testing though.

[jbroman, 2015-10-21 14:05:00]

On 2015/10/21 at 13:29:20, bratell wrote:
> jbroman, I think this size reduction works. When I ran some rendering tests
tests a few weeks ago it seemed all changes on the micro benchmarks were within
noise levels (see
http://storage.googleapis.com/chromium-telemetry/html-results/results-2015-10...
from https://codereview.chromium.org/1377353003/ )
> 
> Would be good if I could have more testing though.

Seems reasonable to me. I've started a Cluster Telemetry run with this patch to
see how it affects the top 10k.

[jbroman, 2015-10-22 14:32:32]

jbroman@chromium.org changed reviewers:
+ chrishtr@chromium.org

[jbroman, 2015-10-22 14:32:33]

Two CT runs on the top 10k have completed.

First one: record_time +1.3%, viewport_picture_size -1.2%
Second one: record_time -0.3%, viewport_picture_size -2.5%

So this CL lgtm, but it's possible it may cause a slight record_time regression.

(+chrishtr in case he wants to weigh in.)

[Daniel Bratell, 2015-10-22 14:52:53]

On 2015/10/22 14:32:33, jbroman wrote:
> Two CT runs on the top 10k have completed.
> 
> First one: record_time +1.3%, viewport_picture_size -1.2%
> Second one: record_time -0.3%, viewport_picture_size -2.5%
> 
> So this CL lgtm, but it's possible it may cause a slight record_time
regression.
> 
> (+chrishtr in case he wants to weigh in.)

Sounds ok. Not sure what viewport_picture_size is but anything size becoming
smaller can't be wrong.

I'll wait for chrishtr to have a chance to see it before checking any boxes.

[jbroman, 2015-10-22 14:53:42]

On 2015/10/22 at 14:52:53, bratell wrote:
> On 2015/10/22 14:32:33, jbroman wrote:
> > Two CT runs on the top 10k have completed.
> > 
> > First one: record_time +1.3%, viewport_picture_size -1.2%
> > Second one: record_time -0.3%, viewport_picture_size -2.5%
> > 
> > So this CL lgtm, but it's possible it may cause a slight record_time
regression.
> > 
> > (+chrishtr in case he wants to weigh in.)
> 
> Sounds ok. Not sure what viewport_picture_size is but anything size becoming
smaller can't be wrong.
> 
> I'll wait for chrishtr to have a chance to see it before checking any boxes.

viewport_picture_size is the memory consumed by the display list and its
associated data.

[chrishtr, 2015-10-22 14:55:29]

The CQ bit was checked by chrishtr@chromium.org

[chrishtr, 2015-10-22 14:55:30]

lgtm

[commit-bot: I haz the power, 2015-10-22 14:55:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1417533009/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1417533009/1

[commit-bot: I haz the power, 2015-10-22 16:55:20]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-22 16:56:25]

Patchset 1 (id:??) landed as
https://crrev.com/84b2acf3ce32315313f954f956084bbcad83238a
Cr-Commit-Position: refs/heads/master@{#355556}