Set IdleHandler timer on background threads a minimum of 30s in the future after initial run.

content/renderer/render_thread_impl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/render_thread_impl.h"
 
 #include <algorithm>
 #include <limits>
 #include <map>
 #include <vector>
@@ skipping 999 matching lines @@
   bool continue_timer = !webkit_shared_timer_suspended_;
 
   if (blink::mainThreadIsolate() &&
       !blink::mainThreadIsolate()->IdleNotification(1000)) {
     continue_timer = true;
   }
   if (!base::DiscardableMemory::ReduceMemoryUsage()) {
     continue_timer = true;
   }
 
-  // Schedule next invocation.
+  // Schedule next invocation. When the tab is originally hidden, an invocation
+  // is scheduled for kInitialIdleHandlerDelayMs in
+  // RenderThreadImpl::WidgetHidden in order to race to a minimal heap.
+  // After that, idle calls can be much less frequent, so run at a maximum of
+  // once every kLongIdleHandlerDelayMs.
   // Dampen the delay using the algorithm (if delay is in seconds):
   //    delay = delay + 1 / (delay + 2)
   // Using floor(delay) has a dampening effect such as:
-  //    1s, 1, 1, 2, 2, 2, 2, 3, 3, ...
+  //    30s, 30, 30, 31, 31, 31, 31, 32, 32, ...

[pasko, 2014/10/09 09:32:14]

with the new formula the series is actually growing slower:
(30s) would be repeated >30 times,
followed by (31s) repeated >30 times,
.. and so on

(I am assuming the series start from kInitialIdleHandlerDelayMs)

That's probably aligned with your intentions, but the comment is now more
confusing.

[sullivan, 2014/10/10 20:55:27]

I added a new patch to try and clarify the comments, but I'm having difficulty
explaining it clearly. Suggestions welcome!

   // If the delay is in milliseconds, the above formula is equivalent to:
   //    delay_ms / 1000 = delay_ms / 1000 + 1 / (delay_ms / 1000 + 2)
   // which is equivalent to
   //    delay_ms = delay_ms + 1000*1000 / (delay_ms + 2000).
-  // Note that idle_notification_delay_in_ms_ would be reset to
-  // kInitialIdleHandlerDelayMs in RenderThreadImpl::WidgetHidden.

[pasko, 2014/10/09 09:32:14]

why deleting this comment?

[sullivan, 2014/10/10 20:55:27]

It was a little misleading, since it's reset to kInitialIdleHandlerDelayMs (1s)
but then below immediately limited to kLongIdleHandlerDelayMs (30s) on the next
run.

So the previous behavior was that the tab is backgrounded and timers would fire
1s, 1s, 1s, 1s, 2s, 2s... and now the behavior is the tab is backgrounded and
timers fire 1s, 30s, 30s, 30s....

I felt that it was clearer to add the comment on line 1020 instead:

When the tab is originally hidden, an invocation
is scheduled for kInitialIdleHandlerDelayMs in
RenderThreadImpl::WidgetHidden in order to race to a minimal heap.
After that, idle calls can be much less frequent, so run at a maximum of
once every kLongIdleHandlerDelayMs.

   if (continue_timer) {
-    ScheduleIdleHandler(idle_notification_delay_in_ms_ +
-                        1000000 / (idle_notification_delay_in_ms_ + 2000));
+    ScheduleIdleHandler(
+        std::max(kLongIdleHandlerDelayMs,
+                 idle_notification_delay_in_ms_ +
+                 1000000 / (idle_notification_delay_in_ms_ + 2000)));
 
   } else {
     idle_timer_.Stop();
   }
 
   FOR_EACH_OBSERVER(RenderProcessObserver, observers_, IdleNotification());
 }
 
 void RenderThreadImpl::IdleHandlerInForegroundTab() {
   // Increase the delay in the same way as in IdleHandler,
@@ skipping 604 matching lines @@
   hidden_widget_count_--;
 
   if (!GetContentClient()->renderer()->RunIdleHandlerWhenWidgetsHidden()) {
     return;
   }
 
   ScheduleIdleHandler(kLongIdleHandlerDelayMs);
 }
 
 }  // namespace content