<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 3, 2017 at 3:33 PM, Chris Peterson <span dir="ltr"><<a href="mailto:cpeterson@mozilla.com" target="_blank">cpeterson@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <br>
    <br>
    <div class="gmail-m_-6068862779398075595moz-cite-prefix">On 2017-04-27 8:49 PM, Ehsan Akhgari
      wrote:<br>
    </div>
    </span><span class="gmail-"><blockquote type="cite">
      <div>Timers are terrible for responsiveness and are almost never
        what you want.  We sometimes use them to lazify some work (do
        this part of the initialization in 10 seconds!) or to do some
        periodic background task (refresh this cache every second) but
        they cause a lot of problems due to the fact that they can
        execute at unpredictable times.  From the perspective of
        improving the responsiveness of Firefox, if your goal is to keep
        the main thread as free as possible when the user's input events
        are about to be handled, the last thing you want is to start
        running one of these timers right before the user clicks or
        types or something like that.  Gecko now supports the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback" target="_blank">requestIdleCallback
          API</a> which allows the caller to request a timer that only
        gets dispatched when the application is idle.  Where possible,
        you should consider re-examining the timers in your areas of the
        code and consider using to idle dispatch where appropriate.<br>
      </div>
    </blockquote>
    <br></span>
    Do we have an idle-aware API for scheduling periodic background
    tasks that have a *minimum* wait time but don't mind some extra
    slack time (i.e. do not refresh the cache more frequently than every
    second)? requestIdleCallback() has a timeout option, but it is a
    *maximum* wait time. The idle callback could be called almost
    immediately, which is not appropriate for periodic background tasks.</div></blockquote><div><br></div><div>Does nsIIdleService::AddIdleObserver() <<a href="https://searchfox.org/mozilla-central/rev/b0e1da2a90ada7e00f265838a3fafd00af33e547/widget/nsIIdleService.idl#55">https://searchfox.org/mozilla-central/rev/b0e1da2a90ada7e00f265838a3fafd00af33e547/widget/nsIIdleService.idl#55</a>> fit this use case?</div><div><br></div><div>(We also have the idle-daily notification BTW that fires at most once a day when the user is idle which is typically used for background maintenance work.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">Does setTimeout() already consider main thread idleness for long
    timeouts like 1 or 10 seconds?<br>
  </div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">No, it doesn't take the main thread idleness into account for anything at all.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">-- <br><div class="gmail_signature"><div dir="ltr">Ehsan<br></div></div>
</div></div>