New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 642176 link

Starred by 2 users
Status: WontFix
Owner:
erikc...@chromium.org
Closed: Aug 2016
Cc:
ccameron@chromium.org
█ aschulman@chromium.org
█ shrike@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Investigate why GIFs use more power in the CA compositor path.

Project Member Reported by erikc...@chromium.org, Aug 29 2016

Comment 1 by shrike@chromium.org, Aug 30 2016

Cc: shrike@chromium.org

Comment 2 by erikc...@chromium.org, Aug 30 2016

Cc: aschulman@chromium.org
The BattOr metrics show the same regression, which is awesome because it means that we should be able to use the traces to narrow down the source of the issue.
Screen Shot 2016-08-29 at 5.41.47 PM.png
411 KB View Download

Comment 3 by aschulman@chromium.org, Aug 30 2016 

Actually there is an open bug with the perf dashboard where the checked traces on the right do not correspond to the traces you see on the left (https://github.com/catapult-project/catapult/issues/2701). You can see that you are encountering this problem in your screenshot. The trace you are hovering over is totally different than the ones you have selected.

I've attached a graph showing the correct two traces that you tried to look at from the MSRs and the BattOr. They both show the NoOverlays consuming ever so slightly more energy than the Overlays.
Screen Shot 2016-08-29 at 9.53.12 PM.png
157 KB View Download

Comment 4 by erikc...@chromium.org, Aug 30 2016

Status: WontFix (was: Assigned)
Wow, that almost cost me a lot of time. Thanks for letting me know about this dashboard bug!

Looks like, as expected, CA compositor performs better
►

Sign in to add a comment