Reduce tile memory size

Reduce tile memory size

One tile memory takes 160 bytes currently.
This patch can reduce the tile memory by removing unnecessary
variables and packing the booleans to 144 bytes.

BUG=341919
Committed: https://crrev.com/0acd2d55393fcbc534b9ed2c61349e5543381658
Cr-Commit-Position: refs/heads/master@{#309504}

[JungJik, 2014-12-16 09:54:16]

jungjik.lee@samsung.com changed reviewers:
+ vmpstr@chromium.org

[JungJik, 2014-12-16 10:04:45]

On 2014/12/16 09:54:16, JungJik wrote:
> mailto:jungjik.lee@samsung.com changed reviewers:
> + mailto:vmpstr@chromium.org

Is the issue still valid? 
When I checked the tile size, it does not take 288 bytes but 168 bytes.
PTAL.

[vmpstr, 2014-12-16 17:40:57]

Can you rebase on tip of tree, since some of those variables are being used, I
think.

Other than that, reducing size is fine, although it's not really a major concern
for tiles.

[JungJik, 2014-12-17 11:21:45]

On 2014/12/16 17:40:57, vmpstr wrote:
> Can you rebase on tip of tree, since some of those variables are being used, I
> think.
> 
> Other than that, reducing size is fine, although it's not really a major
concern
> for tiles.

the patch was based on the top of tree. it was able to compile and passed
cc_unittest.

if you mean "TilePriority::PriorityBin priority_bin;"(being used), 
it is we can get the priority from tile. otherwise the variables are not
referenced from anywhere.

and Could I ask about managed_tile_state?
once it had many properties of tile which are managed in tile_manager.
however now managed_tile_state has mainly DrawInfo and RasterTask.
so do we have the reason that managed_tile_state hold the classes?
maybe can we move them to tile?

thanks for your attention.

[vmpstr, 2014-12-17 17:38:05]

On 2014/12/17 11:21:45, JungJik wrote:
> On 2014/12/16 17:40:57, vmpstr wrote:
> > Can you rebase on tip of tree, since some of those variables are being used,
I
> > think.
> > 
> > Other than that, reducing size is fine, although it's not really a major
> concern
> > for tiles.
> 
> the patch was based on the top of tree. it was able to compile and passed
> cc_unittest.

Oh I missed the fact that you changed tile manager as well.

> 
> if you mean "TilePriority::PriorityBin priority_bin;"(being used), 
> it is we can get the priority from tile. otherwise the variables are not
> referenced from anywhere.
> 
> and Could I ask about managed_tile_state?
> once it had many properties of tile which are managed in tile_manager.
> however now managed_tile_state has mainly DrawInfo and RasterTask.
> so do we have the reason that managed_tile_state hold the classes?
> maybe can we move them to tile?
> 
> thanks for your attention.

You're right. I think at this point we might as well merge everything into tile.
It might be worth having DrawInfo as a separate class (TileDrawInfo or
something) in a separate file. Or maybe it won't add too much if we add it to
tile directly.

[vmpstr, 2014-12-17 17:39:16]

vmpstr@chromium.org changed reviewers:
+ reveman@chromium.org

[vmpstr, 2014-12-17 17:39:16]

+reveman, wdyt about merging mts and tile?

[reveman, 2014-12-17 18:46:00]

On 2014/12/17 17:39:16, vmpstr wrote:
> +reveman, wdyt about merging mts and tile?

Sgtm if it makes the code easier to understand. The only reason afaik for it's
existence is making the code easier to understand be separating the state that
is managed by the tile manager. If it doesn't help with that, then I'm all for
removing it.

[JungJik, 2014-12-22 11:12:35]

On 2014/12/17 18:46:00, reveman wrote:
> On 2014/12/17 17:39:16, vmpstr wrote:
> > +reveman, wdyt about merging mts and tile?
> 
> Sgtm if it makes the code easier to understand. The only reason afaik for it's
> existence is making the code easier to understand be separating the state that
> is managed by the tile manager. If it doesn't help with that, then I'm all for
> removing it.

@vmpstr : Could you review this patch again? we don't need tile_manager_ and
          we have many tiles so I think it's good to pack bool variables.

[vmpstr, 2014-12-22 15:43:35]

lgtm

[JungJik, 2014-12-22 23:54:27]

The CQ bit was checked by jungjik.lee@samsung.com

[commit-bot: I haz the power, 2014-12-22 23:55:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/810713002/20001

[commit-bot: I haz the power, 2014-12-23 00:49:45]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2014-12-23 00:50:52]

Patchset 2 (id:??) landed as
https://crrev.com/0acd2d55393fcbc534b9ed2c61349e5543381658
Cr-Commit-Position: refs/heads/master@{#309504}