Reduce CPU usage of download shelf UI. (both MD and pre-MD shelves)

chrome/browser/ui/views/download/download_item_view.cc

Index: chrome/browser/ui/views/download/download_item_view.cc
diff --git a/chrome/browser/ui/views/download/download_item_view.cc b/chrome/browser/ui/views/download/download_item_view.cc
index 20778df043687457b2187fcd773e99ac1786020b..121834e8d472a9ef6a2fe2d208852da6549a2cc8 100644
--- a/chrome/browser/ui/views/download/download_item_view.cc
+++ b/chrome/browser/ui/views/download/download_item_view.cc
@@ -241,10 +241,10 @@ void DownloadItemView::StartDownloadProgress() {
   if (progress_timer_.IsRunning())
     return;
   progress_start_time_ = base::TimeTicks::Now();
-  progress_timer_.Start(
-      FROM_HERE,
-      base::TimeDelta::FromMilliseconds(DownloadShelf::kProgressRateMs),
-      base::Bind(&DownloadItemView::SchedulePaint, base::Unretained(this)));
+  progress_timer_.Start(FROM_HERE, base::TimeDelta::FromMilliseconds(
+                                       DownloadShelf::kProgressRateMs),
+                        base::Bind(&DownloadItemView::ProgressTimerFired,
+                                   base::Unretained(this)));
 }
 
 void DownloadItemView::StopDownloadProgress() {
@@ -286,6 +286,7 @@ void DownloadItemView::OnDownloadUpdated(DownloadItem* download_item) {
       case DownloadItem::IN_PROGRESS:
         download()->IsPaused() ?
             StopDownloadProgress() : StartDownloadProgress();
+        SchedulePaint();
         LoadIconIfItemPathChanged();
         break;
       case DownloadItem::INTERRUPTED:
@@ -329,11 +330,6 @@ void DownloadItemView::OnDownloadUpdated(DownloadItem* download_item) {
   }
 
   UpdateAccessibleName();
-
-  // We use the parent's (DownloadShelfView's) SchedulePaint, since there
-  // are spaces between each DownloadItemView that the parent is responsible
-  // for painting.
-  shelf_->SchedulePaint();
 }
 
 void DownloadItemView::OnDownloadDestroyed(DownloadItem* download) {
@@ -1398,3 +1394,10 @@ void DownloadItemView::AnimateStateTransition(State from, State to,
     animation->Reset((to == HOT) ? 1.0 : 0.0);
   }
 }
+
+void DownloadItemView::ProgressTimerFired() {
+  // Only repaint for the indeterminate size case. Otherwise, we'll repaint only
+  // when there's an update notified via OnDownloadUpdated().
+  if (model_.PercentComplete() < 0)
+    SchedulePaint();

[Evan Stade, 2016/01/06 19:34:10]

I reverted the change for indeterminate size downloads, but CPU usage is pretty
high again in that case.

I tried only scheduling a paint for the progress rect but it didn't seem to make
a difference. Further down the line I want to try painting the progress
indicator on its own layer and only invalidating that layer, but that will
require more investigation so I'll leave it for a later date.

If we can't find a way to optimize this animation, I would contend we should
change the animation to something that looks good at 2fps because in its current
state it seems wasteful of CPU (and battery/electricity) as no actual
information is being conveyed at 30fps that isn't conveyed at 2fps.

[asanka, 2016/01/06 19:44:28]

Understood. I agree that we aren't conveying 30fps of information and I think we
could  increase kProgressRateMs substantially without anyone noticing. But I
think our cutoff would be less than 500ms.

This change addresses my concern that we were depending on the byte count update
timer frequency for a UI animation. I'll defer to others on what a good
animation rate is.

+}