Allow requesting a minimum time budget

[cramforce]

I my experience every use of requestIdleCallback will eventually have a wrapper like this one:

function requestIdleCallback(win, minimumTimeRemaining, timeout, fn) {
  const before = Date.now();
  win.requestIdleCallback(info => {
    if (info.timeRemaining() < minimumTimeRemaining) {
      const remainingTimeout = timeout - (Date.now() - before);
      if (remainingTimeout <= 0) {
        fn();
      } else {
        requestIdleCallback(win, minimumTimeRemaining, remainingTimeout, fn);
      }
    } else {
      fn();
    }
  });
}

…where rIC is called recursively until a time budget under some requirement is reached. Among other things this requires managing the timeout in user code, because one will typically want a timeout across these calls.

This would be fixed by allowing the caller to pass in something like minimumTimeRemaining into the rIC options object.

[igrigorik]

@cramforce you probably want to use performance.now() instead of Date.now()... :-)

We did discuss ~this earlier: https://github.com/w3c/requestidlecallback/issues/28#issuecomment-216604770.

[cramforce]

@igrigorik the point is that the code is complicated and buggy. This needs to be solved in the platform.

[igrigorik]

Yep, no disagreement there. I'm just linking to previous discussions on this for context.

[farre]

I see the need for this, but I was thinking of how this would work when a script using minimum budget runs in contexts with different idle profiles. Wouldn't a minimum time budget make a developer less encouraged in splitting up the work a callback performs? This would favor platforms with less idle time, which could be a problem. This is of course the case with rIC already, but could this make it worse?

[cramforce]

There are lots of tasks that cannot be split up in any meaningful way: E.g. load a Youtube or Instagram embed. Given no better choice it is typically best to do these tasks when the user is least likely to interact.

On Mon, Oct 23, 2017 at 4:40 AM, Andreas Farre notifications@github.com wrote:

I see the need for this, but I was thinking of how this would work when a script using minimum budget runs in contexts with different idle profiles. Wouldn't a minimum time budget make a developer less encouraged in splitting up the work a callback performs? This would favor platforms with less idle time, which could be a problem. This is of course the case with rIC already, but could this make it worse?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/requestidlecallback/issues/49#issuecomment-338631957, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFeT_3fG2V-H-hB7UO1LwAnYN9VCSV2ks5svHtBgaJpZM4Kacpz .

[farre]

@cramforce Right, I didn't notice that the timeout parameter to the rIC-wrapper was a "soft" timeout. This would introduce another type of timeout, how do you see the two timeouts interacting if both are present? Would the hard timeout count from 'now' or from when we give up trying to get a sufficiently large value from timeRemaining()?

[cramforce]

I think that if requestIdleCallback supported something like minimumTimeRemaining, then we would not need another timeout type.

[clelland]

@shaseley, is this something that we should add to the spec?