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

content/renderer/render_thread_impl.cc

Index: content/renderer/render_thread_impl.cc
diff --git a/content/renderer/render_thread_impl.cc b/content/renderer/render_thread_impl.cc
index 4a1a1bccc401221de6ccb4183f98ed0b8d45abf9..3842bca15684605283d42e4376996aeb1eb0c7fa 100644
--- a/content/renderer/render_thread_impl.cc
+++ b/content/renderer/render_thread_impl.cc
@@ -1017,20 +1017,24 @@ void RenderThreadImpl::IdleHandler() {
     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();