背景タスクの協同的なスケジュール法 — Cooperative Scheduling of Background Tasks

1. 依存関係

【 この節の和訳は、省略する。 】 ◎ The terms browsing context , event loop, event loop processing model, spin the event loop, fully active, tasks, task source, task queues, queue a task, microtask queue, list of active timers, setTimeout, setInterval, requestAnimationFrame and report the error are defined in [html]. ◎ The terms current high resolution time and DOMHighResTimestamp are defined in [hr-time-2]. ◎ The term conforming implementation is defined in [WebIDL]. ◎ The term hidden is defined in [page-visibility].

2. 序論

~web頁では、~UAの~event~loop上で，背景~taskを実行することが求められることが多い。 背景~taskとは、 “時間に厳しい” ~task 【 time-critical — 所定の刻限までに終えることが求められる~task 】 ではないが，有意な時間はかかるような、計算~taskである。 そのような~taskの例には、［ 解析~dataを記録する ／ 長時間~稼働し続けるような~data処理~演算 ／ ~client側~templating ／ 近い未来に可視になると見込まれる内容を 事前に具現化しておく ］などが挙げられる。 これらの~taskは、~event~loopを，時間に厳しい他の演算（例えば［ 利用者~入力に反応する ／ `requestAnimationFrame()$m を利用する ~scriptに基づく~animation ］など）と共有しなければならない。 これらの背景~taskは、概して，［ `setTimeout()$m を利用して~callbackを~scheduleして，その~callbackにて背景~taskを稼働する ］ことにより遂行されている。 ◎ Web pages often want to execute computation tasks on the browser's event loop which are not time-critical, but might take a significant portion of time to perform. Examples of such background tasks include recording analytics data, long running data processing operations, client-side templating and pre-rendering of content likely to become visible in the near future. These tasks must share the event loop with other time-critical operations, such as reacting to input and performing script-based animations using requestAnimationFrame. These background tasks are typically performed by scheduling a callback using setTimeout and running the background task during that callback.

この~approachの欠点は： ◎ A disadvantage of this approach is that＼

• ~scriptの作者には、 `setTimeout()$m に与えた~callbackが［ 時間に厳しいのか，~UAが遊休~中になるまで遅延できるのか ］について，~UAに伝えるすべがない。 ◎ the author of the script has no way to inform the user-agent as to whether a given setTimeout callback is time-critical or could be delayed until the browser is otherwise idle.＼
• ~UAは、［［ 時間に厳しい演算の遅延や，~jankその他の利用者が知覚し得るような遅延 ］をもたらすことなく，いつまで~callbackを実行し続けられるか ］についての情報を，~callbackに供せない。 ◎ In addition, the user agent isn't able to provide the callback with any information about how long it can continue to execute without delaying time-critical operations and causing jank or other user-perceptible delays.＼

その結果，作者にとっては、単純に［ 微小な値を引数に `setTimeout()$m を~callして，その~callbackの中で最小限に細分化された仕事をこなし，追加の仕事を `setTimeout()$m への別の~callで~scheduleし直す ］のが，最も容易になるが、これは： ◎ As a result, the easiest way forward is for the author is to simply call setTimeout with a very small value, and then execute the minimum possible chunk of work in the resulting callback and reschedule additional work with another call to setTimeout.＼

• 多数の小さな~taskを~UAの~event~loopに~postして，それらの実行を~scheduleすることによる，余計な~overheadがあるので、最適とは言えない。 ◎ This is less than optimal because there is extra overhead from having to post many small tasks on the user agent's event loop and schedule their execution.＼
• ~UAが，［ これらの~callbackのそれぞれを，時間に厳しい他の仕事の合間に適切に差挟む ］ことに依拠しているが、そうするのは困難である — ~UAは、それぞれの~callbackが要する時間について正確0な前提を置けないので。 ◎ It also relies on the user-agent interleaving other time-critical work between each of these callbacks appropriately, which is difficult since the user-agent can't make accurate assumptions on how long each of these callbacks are likely to take.

この文書にて述べる~APIにより、~script作者は，［ ~callbackを，~UAが遊休~中になったなら~callされるように~scheduleする ］よう，~UAに要請することが可能になる。 ~UAは、その~callbackに［ 自身の見積もりによる，自身が遊休~中であり続ける時間 ］を，刻限（ deadline ）として渡す。 頁~作者は、その刻限を利用して，［ ~callbackが実行する背景~taskが，~animationや, 利用者~入力に対する応答などの~~遅延に厳しい~eventに波及しない ］ことを確保できる。 ◎ The API described in this document allows script authors to request the user-agent to schedule a callback when it would otherwise be idle. The user agent provides an estimation of how long it expects to remain idle as a deadline passed to the callback. The page author can use the deadline to ensure that these background tasks don't impact latency-critical events such as animation and input response.

この~APIを利用して、背景~taskを書く例を示す： ◎ Here is an example of using the API to write a background task.

<!DOCTYPE html>
<title>
`requestIdleCallback()$m を利用して、背景~taskを~scheduleする
◎
Scheduling background tasks using requestIdleCallback
</title>
<script>
var %requestId = 0;
var %pointsTotal = 0;
var %pointsInside = 0;

function piStep() {
  var %r = 10;
  var %x = Math.random() * %r * 2 - %r;
  var %y = Math.random() * %r * 2 - %r;
  return (Math.pow(%x, 2) + Math.pow(%y, 2) < Math.pow(%r, 2))
}
function refinePi(%deadline) {
  while (%deadline.timeRemaining() > 0) {
    if (piStep())
      %pointsInside++;
    %pointsTotal++;
  }
  var %currentEstimate = (4 * %pointsInside / %pointsTotal);
  var %textElement = document.getElementById("piEstimate");
  %textElement.innerHTML="Pi Estimate: " + %currentEstimate;
  %requestId = window.requestIdleCallback(refinePi);
}
function start() {
  %requestId = window.requestIdleCallback(refinePi);
}
function stop() {
  if (%requestId)
    window.cancelIdleCallback(%requestId);
  %requestId = 0;
}
</script>
<button onclick="start()">クリックで開始</button>
<button onclick="stop()">クリックで停止</button>
<div id="piEstimate">まだ開始されていない</div>

【この訳に固有の表記規約】

この訳の~algoや定義の記述に利用されている各種記号（ ~LET, 此れ, ~IF, ~THROW 等々）の意味や定義の詳細は、~SYMBOL_DEF_REFを~~参照されたし。

原文にて `HTML5$r 仕様による定義を参照している用語は、便宜のため，この訳では WHATWG HTML 仕様（の和訳）による定義を参照している。

3. 遊休~期間

~UAの~main-threadは、［ 入力~処理, および 所与の~frame用の 具現化と組成-法 ］が完了してから，［ 次の~frameが始まる ／ 別の処理待ち~taskが稼働可能になる ／ 利用者からの入力を受取る ］のいずれかが生じるまでは、遊休~中になることが多い。 この仕様は、この遊休~中の間に ~callbackの実行を~scheduleする手段を， `requestIdleCallback()$m を介して供する。 ◎ After input processing, rendering and compositing for a given frame has been completed, the user agent's main thread often becomes idle until either: the next frame begins; another pending task becomes eligible to run; or user input is received. This specification provides a means to schedule execution of callbacks during this otherwise idle time via a requestIdleCallback API.

`requestIdleCallback()$m を介して~postされた~callbackには、~UAにより定義される遊休~期間にて稼働可能になる。 遊休~callback 【 “~UAの遊休~期間に~callされるものとして，作者が与える~callback関数” 】 の稼働-時には、現在の遊休~期間の終端に対応する刻限が渡される。 何をもって遊休~期間とするかは，~UAにより定義されるが、［ ~UA自身が遊休~中にあると予期するような， “~~静止” 期間 ］に生じるものと期待される。 ◎ Callbacks posted via the requestIdleCallback API become eligible to run during user agent defined idle periods. When an idle callback is run it will be given a deadline which corresponds to the end of the current idle period. The decision as to what constitutes an idle period is user agent defined, however the expectation is that they occur in periods of quiescence where the browser expects to be idle.

遊休~期間の一例として、次の図に示されるような，［ 所与の~frameを~screenへ~commitしてから，作動中の~animationの間に次の~frameの処理を開始するまで ］の時区間が挙げられる。 そのような遊休~期間は，~animationが作動中にあり, ~screenが更新され続ける間に，高頻度に生じるが、概して とても短くなる（すなわち、~vsync周期が 60Hz の機器においては約 16ms 以下）。 ◎ One example of an idle period is the time between committing a given frame to the screen and starting processing on the next frame during active animations, as shown in Figure 1 Example of an inter-frame idle period . Such idle periods will occur frequently during active animations and screen updates, but will typically be very short (i.e., less than 16ms for devices with a 60Hz vsync cycle).

注記： ~web開発者は、遊休~callbackの間に その演算が遂行するすべての仕事を【非同期的なものも含めて】勘定に入れるよう，注意深くなるべきである。 一部の演算 — 例えば、~promiseを解決する, あるいは頁~layoutを誘発するものなど — は、遊休~callbackが終わった後にも，後続の~taskを~scheduleさせ得る。 そのような事例では、刻限を過ぎる前に，これらの演算を次の~frame刻限の前に遂行できるように先送りするべきである。 ◎ The web-developer should be careful to account for all work performed by operations during an idle callback. Some operations, such as resolving a promise or triggering a page layout, may cause subsequent tasks to be scheduled to run after the idle callback has finished. In such cases, the application should account for this additional work by yielding before the deadline expires to allow these operations to be performed before the next frame deadline.

遊休~期間の別の例として、~screenの更新がないときの遊休~~状態が挙げられる。 そのような状況では、~UAが遊休~期間を早々に終端させ得るような差し迫った~taskがないときでも、いつ起きるか予測-不能な~task — 利用者~入力の処理など — により，利用者が知覚し得る遅延が起きないようにするため、遊休~期間の長さは， 50ms を上限にするべきである。 遊休~期間が終わり，まだ遊休~中にあるならば、~UAは，次の図に示されるように，別の遊休~期間を~scheduleできる — 背景~仕事は、複数の遊休~期間にわたり，何回でも存続し続けられる。 ◎ Another example of an idle period is when the user agent is idle with no screen updates occurring. In such a situation the user agent may have no upcoming tasks with which it can bound the end of the idle period. In order to avoid causing user-perceptible delays in unpredictable tasks, such as processing of user input, the length of these idle periods should be capped to a maximum value of 50ms. Once an idle period is finished the user agent can schedule another idle period if it remains idle, as shown in Figure 2 Example of an idle period when there are no pending frame updates , to enable background work to continue to occur over longer idle time periods.

遊休~期間の間，~UAは、各 遊休~callbackを［ 遊休~期間が終端するか, または 稼働可能とされている遊休~callbackをすべて稼働し終える ］まで、要請された順に稼働することになる。 すなわち、~UAは必ずしも，~postされた遊休~callbackすべてを単独の遊休~期間~内に稼働させることはない。 残りの遊休~taskは、次の遊休~期間にも稼働可能であり続ける。 ◎ During an idle period the user agent will run idle callbacks in FIFO order until either the idle period ends or there are no more idle callbacks eligible to be run. As such, the user agent will not necessarily run all currently posted idle callbacks within a single idle period. Any remaining idle tasks are eligible to run during the next idle period.

注記： 最良の処理能を発揮させるためには、開発者には，有意義な仕事を遂行しない不必要な~callback（例： `requestAnimationFrame()^m, `setTimeout()^m, 等々）は排することが奨励される — そのような~callbackを発火させ続けて，各~eventに反応するのを待機するのでなく、各~eventに反応する~callbackを，可用になり次第 必要に応じて~scheduleするほうがよい。 この~patternにより、全体的な効率性は改善され、~UAは，背景~仕事の巨大blockをより効率的に遂行できるような，長い（ 50ms までの）遊休~callbackを~scheduleすることが可能になる。 ◎ To deliver the best performance developers are encouraged to eliminate unnecessary callbacks (e.g. requestAnimationFrame, setTimeout, and so on) that do not perform meaningful work; do not keep such callbacks firing and waiting for events to react, instead schedule them as necessary to react to events once they become available. Such pattern improves overall efficiency, and enables the user agent to schedule long idle callbacks (up to 50ms) that can be used to efficiently perform large blocks of background work.

現在の遊休~期間にて稼働可能であるとされる遊休~taskは、その遊休~期間が開始される前に~postされたものに限られる。 したがって、ある遊休~callbackが `requestIdleCallback()$m を利用して別の~callbackを~postしたならば、その~callbackは，現在の遊休~期間においては稼働しないことになる。 これにより、遊休~callbackは，自身の仕事を所与の刻限までに完了できない場合には，未来の遊休~期間にまた稼働させるように自身を再度~postできるようになる。 すなわち、次の例の様に，遊休~期間が短か過ぎるときは先送りする~code~patternも可能になる： ◎ Only idle tasks which posted before the start of the current idle period are eligible to be run during the current idle period. As a result, if an idle callback posts another callback using requestIdleCallback, this subsequent callback won't be run during the current idle period. This enables idle callbacks to re-post themselves to be run in a future idle period if they cannot complete their work by a given deadline - i.e., allowing code patterns like the following example, without causing the callback to be repeatedly executed during a too-short idle period:

function doWork(%deadline) {
  if (%deadline.timeRemaining() <= 5) {
    /* 
この仕事は 5ms 以上かかるので、刻限の余裕が十分になるまで，先送りする。
◎
This will take more than 5ms so wait until we get called back with a long enough deadline.
 */
    requestIdleCallback(doWork);
    return;
  }
  /* 
何らかの仕事を行う…
◎
do work...
 */
}

新たに~postされた遊休~callbackは、`遊休~callback~list$の末尾に付加され，次の遊休~期間の開始~時に`稼働可能$にされる。 したがって，再~postされる~callbackたちは、~round-robin式に — 各~callbackが［ 同じ遊休~期間における，より早期の~taskにより再~postされた~callback ］より前に稼働する機会が得られるように — 稼働することが確保される。 ◎ At the start of the next idle period newly posted idle callbacks are appended to the end of the runnable idle callback list, thus ensuring that reposting callbacks will be run round-robin style, with each callback getting a chance to be run before that of an earlier task's reposted callback.

注記： この仕様の将来~versionでは、他の~schedule方策も許容され得る。 例えば、遊休~callbackを同じ遊休~期間の中で~scheduleしたり、少なくとも X ~milli秒 以上の遊休~期間, 等々。 現在の仕様は、~callbackが［ 自身の~logicを実行したり，次の遊休~期間に自身を再~postできる ］ような，次の遊休~期間に~scheduleする事例のみを~supportする ◎ Future versions of this specification could allow other scheduling strategies. For example, schedule idle callback within the same idle period, a period that has at least X milliseconds of idle time, and so on. Current specification only supports the case for scheduling into the next idle period, at which time the callback can execute its logic, or repost itself into the next idle period.

~UAは、~web頁が利用者から可視でない下では、機器の電力消費を抑えるためなど，遊休~期間の生成を間引くこともできる — 例えば，毎 10 秒ごとに一回にするなど。 ◎ When the user agent determines that the web page is not user visible it can throttle idle periods to reduce the power usage of the device, for example, only triggering an idle period every 10 seconds rather than continuously.

最後に，目立たないが重要な点として、頁の負荷が高い間は，~UAが遊休~期間として可用な CPU 時間をあてがう保証-はないことに注意。 ~UAが遊休~期間を何ら~scheduleしないことも，まったく受容-可能であり、その場合， `requestIdleCallback()$m を介して~postされた遊休~callbackは、不定期に先送りされることにもなり得る。 作者は、~callbackを遊休~期間~内に実行させたいが，ある時間までに実行することを要する場合には、 `requestIdleCallback()$m の %options 引数に `timeout$m ~memberを供せる — 遊休~期間~内に~callbackが実行される前に，指定された~timeoutに達した場合、それを実行する~taskが~queueされる。 ◎ A final subtlety to note is that there is no guarantee that a user agent will have any idle CPU time available during heavy page load. As such, it is entirely acceptable that the user agent does not schedule any idle period, which would result in the idle callbacks posted via the requestIdleCallback API being postponed for a potentially unbounded amount of time. For cases where the author prefers to execute the callback within an idle period, but requires a time bound within which it can be executed, the author can provide the timeout property in the options argument to requestIdleCallback: if the specified timeout is reached before the callback is executed within an idle period, a task is queued to execute it.

刻限の上限 50ms は、 `RESPONSETIME$r の研究から導出されたものである — そこでは、利用者~入力に対する 100ms 内の応答は，一般に人にとっては瞬間的であると知覚されることが示されている。 したがって，遊休~taskが始まった直後に利用者~入力が生じたとしても、~UAには，［ 利用者から知覚されることなく 入力に応答するための猶予 ］として， 50ms が残されることになる。 ◎ The maximum deadline of 50ms is derived from studies [RESPONSETIME] which show that that a response to user input within 100ms is generally perceived as instantaneous to humans. Capping idle deadlines to 50ms means that even if the user input occurs immediately after the idle task has begun, the user agent still has a remaining 50ms in which to respond to the user input without producing user perceptible lag.

4. 適合性

【 この節の内容は W3C 日本語訳 共通ページ に委譲 】

5. `Window^I ~interfaceに対する拡張

`requestIdleCallback()$m 演算は、下の IDL 片による部分的~interfaceにより， `Window$I ~obj上に公開される。 `HTML5$r ◎ The partial interface in the IDL fragment below is used to expose the requestIdleCallback operation on the Window object. [HTML5]

partial interface `Window$I {
  unsigned long `requestIdleCallback$m(
      `IdleRequestCallback$I %callback,
      `IdleRequestOptions$I %options
  );
  void `cancelIdleCallback$m(unsigned long %handle);
};

dictionary `IdleRequestOptions@I {
  unsigned long `timeout@m;
};

[`Exposed$=Window]
interface `IdleDeadline@I {
  `DOMHighResTimeStamp$I `timeRemaining$m();
  readonly attribute boolean `didTimeout$m;
};

callback `IdleRequestCallback@I = void (`IdleDeadline$I %deadline);

各 `Window$I ~objは、次のものを持つ： ◎ Each Window has:

`遊休~callback~list@

一連の`遊休~callback$からなる~listであり，初期~時は空で~MUST。 ~list内の各 `遊休~callback$の`~handle$は、当の `Window^I ~objが存続する限り，一意にされ~MUST。 ◎ A list of idle request callbacks. The list MUST be initially empty and each entry in this list is identified by a number, which MUST be unique within the list for the lifetime of the Window object. ◎ A list of runnable idle callbacks. The list MUST be initially empty and each entry in this list is identified by a number, which MUST be unique within the list of the lifetime of the Window object.

【 この~listは、原文では， 2 つの~list `要請-済み遊休~callback~list@, `稼働可能な遊休~callback~list@ に分けて管理されているが、この訳では 1 つの~listに集約した上で，各`遊休~callback$の`稼働可能$により管理する。 そうした方がずっと簡潔に記述できるので。 】

`遊休~callback識別子@

整数。 初期~時は 0 にされ~MUST。 ◎ An idle callback identifier, which is a number which MUST initially be zero.

`最後の遊休~期間~刻限@

`DOMHighResTimeStamp$I 値。 初期~時は 0 にされ~MUST。 ◎ A last idle period deadline, which is a DOMHighResTimeStamp which MUST initially be zero.

6. 処理~model

7. ~privacyと保安

~UAは、遊休~callbackの~schedule時に，自身が予期する，遊休であり続ける時間の見積もりを供する。 この情報は、その~frameの中で 他の~app~taskや関係する~browserの仕事にかかった時間を見積もるために利用できる。 しかしながら，開発者はすでに、他の手段を介してこの情報に~accessできる — 例えば、 `requestAnimationFrame()^m を介して~frameの始まりを~markして，次の~frameの時刻を見積もって，その情報を~callbackの中での “残り時間” を算出するために利用するなど。 ◎ When an idle callback is scheduled the user agent provides an estimate of how long it expects to remain idle. This information can be used to estimate the time taken by other application tasks and related browser work within that frame. However, developers can already access this information via other means - e.g. mark beginning of the frame via requestAnimationFrame, estimate the time of the next frame, and use that information to compute "remaining time" within any callback.

~cache攻撃と統計的指紋収集を軽減するため、 `IdleDeadline$I ~interfaceから返される時間の分解能は、［ `HR-TIME-2$r に定義される `Performance^I ~interface ］と同じく 5 ~micro秒までの細かさに設定される 【計時~攻撃を防止するに十分な精度にとどめる】 べきである。 ◎ To mitigate cache and statistical fingerprinting attacks, the resolution of the time estimates returned by the IdleDeadline interface should be set to the same 5 microsecond minimum as the Performance interface defined in [HR-TIME].