DevTools: Reverse priority order of timeline cpu utilization groups.

DevTools: Reverse priority order of timeline cpu utilization groups.

Keep less intensive categories at the bottom of the chart.

BUG=497166
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=197927

[alph, 2015-06-24 16:48:49]

alph@chromium.org changed reviewers:
+ pfeldman@chromium.org, yurys@chromium.org

[alph, 2015-06-25 14:27:55]

alph@chromium.org changed reviewers:
- yurys@chromium.org

[yurys, 2015-06-25 15:40:14]

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

[yurys, 2015-06-25 15:40:14]

I don't see big advantage of the new order over the current one. We may try to
make transition between adjusent bars smooth.

[alph, 2015-06-26 08:54:05]

On 2015/06/25 15:40:14, yurys wrote:
> I don't see big advantage of the new order over the current one. We may try to
> make transition between adjusent bars smooth.

Ok, let me explain in more details.
It comes from an assumption that in average JS is responsible for more CPU
utilization than other categories.
More CPU utilization leads to higher utilization bars, higher bars means higher
deviation of bars.
That in turn makes other category bars that lay on top of JS ones to be very
unaligned and look teared apart.

[yurys, 2015-06-26 09:08:53]

On 2015/06/26 08:54:05, alph wrote:
> On 2015/06/25 15:40:14, yurys wrote:
> > I don't see big advantage of the new order over the current one. We may try
to
> > make transition between adjusent bars smooth.
> 
> Ok, let me explain in more details.
> It comes from an assumption that in average JS is responsible for more CPU
> utilization than other categories.
> More CPU utilization leads to higher utilization bars, higher bars means
higher
> deviation of bars.
> That in turn makes other category bars that lay on top of JS ones to be very
> unaligned and look teared apart.

On the other hand, we have examples where most of the time is spent in paint
category. Should we rearrange the categories for such examples as well?

[alph, 2015-06-26 09:12:30]

On 2015/06/26 09:08:53, yurys wrote:
> On 2015/06/26 08:54:05, alph wrote:
> > On 2015/06/25 15:40:14, yurys wrote:
> > > I don't see big advantage of the new order over the current one. We may
try
> to
> > > make transition between adjusent bars smooth.
> > 
> > Ok, let me explain in more details.
> > It comes from an assumption that in average JS is responsible for more CPU
> > utilization than other categories.
> > More CPU utilization leads to higher utilization bars, higher bars means
> higher
> > deviation of bars.
> > That in turn makes other category bars that lay on top of JS ones to be very
> > unaligned and look teared apart.
> 
> On the other hand, we have examples where most of the time is spent in paint
> category. Should we rearrange the categories for such examples as well?

Yes, there always be extreme cases, but we can make it look better for the most
common case (high JS), which makes it look better in average.

[yurys, 2015-06-26 09:14:09]

On 2015/06/26 09:12:30, alph wrote:
> On 2015/06/26 09:08:53, yurys wrote:
> > On 2015/06/26 08:54:05, alph wrote:
> > > On 2015/06/25 15:40:14, yurys wrote:
> > > > I don't see big advantage of the new order over the current one. We may
> try
> > to
> > > > make transition between adjusent bars smooth.
> > > 
> > > Ok, let me explain in more details.
> > > It comes from an assumption that in average JS is responsible for more CPU
> > > utilization than other categories.
> > > More CPU utilization leads to higher utilization bars, higher bars means
> > higher
> > > deviation of bars.
> > > That in turn makes other category bars that lay on top of JS ones to be
very
> > > unaligned and look teared apart.
> > 
> > On the other hand, we have examples where most of the time is spent in paint
> > category. Should we rearrange the categories for such examples as well?
> 
> Yes, there always be extreme cases, but we can make it look better for the
most
> common case (high JS), which makes it look better in average.

Do you have any data proving that it is the most common case for our users?

[pfeldman, 2015-06-26 09:18:04]

I can see it as being slightly more user-friendly since it produces a more
continuous visualization, so I trust alph with this experiment. Yury, are you
against it or are you neutral?

[alph, 2015-06-26 09:19:40]

On 2015/06/26 09:14:09, yurys wrote:
> On 2015/06/26 09:12:30, alph wrote:
> > On 2015/06/26 09:08:53, yurys wrote:
> > > On 2015/06/26 08:54:05, alph wrote:
> > > > On 2015/06/25 15:40:14, yurys wrote:
> > > > > I don't see big advantage of the new order over the current one. We
may
> > try
> > > to
> > > > > make transition between adjusent bars smooth.
> > > > 
> > > > Ok, let me explain in more details.
> > > > It comes from an assumption that in average JS is responsible for more
CPU
> > > > utilization than other categories.
> > > > More CPU utilization leads to higher utilization bars, higher bars means
> > > higher
> > > > deviation of bars.
> > > > That in turn makes other category bars that lay on top of JS ones to be
> very
> > > > unaligned and look teared apart.
> > > 
> > > On the other hand, we have examples where most of the time is spent in
paint
> > > category. Should we rearrange the categories for such examples as well?
> > 
> > Yes, there always be extreme cases, but we can make it look better for the
> most
> > common case (high JS), which makes it look better in average.
> 
> Do you have any data proving that it is the most common case for our users?

No, this is just my perception. And I don't it's worth to collect one.
Anyway if we have no data, that means any order is ok. So why do you resist with
the change?

[yurys, 2015-06-26 09:45:05]

On 2015/06/26 09:18:04, pfeldman wrote:
> I can see it as being slightly more user-friendly since it produces a more
> continuous visualization, so I trust alph with this experiment. Yury, are you
> against it or are you neutral?

My point is that it improves visual perception for the js-heavy sites while
making it worth for the paint-intensive ones. Since we have no data proving that
the js-heavy is more common case for our users I don't think this is necessarily
an improvement and with such approach we can be shuffling categories endlessly.
I don't mind the change per se, my concern is that we don't have a clear
criteria on when we should stop rearranging the categories.

[pfeldman, 2015-06-26 15:23:15]

lets try it out?

lgtm

[alph, 2015-06-26 15:30:00]

The CQ bit was checked by alph@chromium.org

[commit-bot: I haz the power, 2015-06-26 15:30:13]

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

[commit-bot: I haz the power, 2015-06-26 16:34:56]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=197927