1. 序論
◎非規範的~web~pageでは、 ~UAの~event~loop上で，背景~taskを実行することが求まれることが多い。 背景~taskとは、 “時間に厳しい” 【 `time-critical^en — 所定の刻限までに終えることが求まれる】 ~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の作者は、 次について~UAに伝えるすべがない ⇒ `setTimeout()$m に与えた~callbackは、 時間に厳しいのか，~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は、次についての情報を~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に要する~~時間について正確aな前提を置けないので。 ◎ 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は、［ ~callbackを［ ~UAが遊休~中になったなら~callされる ］よう~scheduleするよう，~UAに要請する ］ことを~script作者に許容する。 ~UAは、 その~callbackに［ 自身の見積もりによる，自身が遊休~中であり続ける時間 ］を刻限（ `deadline^en ）として渡す。 ~page作者は、 その刻限を利用して，~callbackが実行する背景~taskが待時間に厳しい~event — ~animation, 利用者~入力に対する応答など — には影響iしないことを確保できる。 ◎ 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>
【この訳に特有な表記規約】
◎表記記号2. 遊休~期間
◎非規範的~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. 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).
稼働する 描画
更新
遊休
~callback 遊休
~callback
稼働する ~taskを
稼働する 描画
更新
遊休
~callback
注記： ~web開発者は、 遊休~callbackの間に その演算が遂行するすべての作業を【非同期的なものも含めて】勘定に入れるよう気を付けるべきである。 一部の演算 — 例：~promiseを解決する, ~page~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 ］は~UAには無いときでも［ いつ起きるか予測-不能な~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, to enable background work to continue to occur over longer idle time periods.
更新
遊休
~callback 遊休
~callback
遊休
~callback 遊休
~callback
利用者~入力
更新 …
遊休~期間の間，~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$の末尾に付加され、 その`稼働-可能か$ は，次回の遊休~期間の開始-時に ~T にされる。 したがって，再~postされる~callbackたちは、 ~round-robin式に — 各~callbackが［ 同じ遊休~期間における，より早期の~taskにより再~postされた~callback ］より前に稼働する機会cが得られるように — 稼働することが確保される。 ◎ 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~pageが利用者から可視でないと決定した場合には， 機器の電力消費を抑制するためなど， 遊休~期間の生成を間引くこともできる — 例えば、 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.
最後に，目立たないが~~重要な点として、 ~pageの負荷が高い間は，~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.
3. 適合性
【 この節の内容は ~W3C日本語訳 共通~page に移譲。 】
4. `Window^I ~interfaceに対する拡張
`requestIdleCallback()$m 演算は、 次の~IDL片による部分的~interfaceにより， `Window$I ~objに公開される。 ◎ The partial interface in the IDL fragment below is used to expose the requestIdleCallback() operation on the Window object.
partial interface `Window$I {
`unsigned long$ `requestIdleCallback$m(
`IdleRequestCallback$I %callback,
optional `IdleRequestOptions$I %options = {}
);
`undefined$ `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 = `undefined$ (`IdleDeadline$I %deadline);
各 `Window$I ~objは、 次に挙げるものを持つ： ◎ Each Window has:
-
`遊休~callback~list@ ⇒ 一連の`遊休~callback$からなる~listであり， 初期~時は空になるモノトスル。 この~list内の各 `遊休~callback$の`~handle$は、 当の `Window^I ~objが存続する限り，~list内で一意になるモノトスル。
【 この~listは、 原文では， 2 つの~list `要請-済み遊休~callback~list@, `稼働-可能な遊休~callback~list@ に分けて管理されているが、 この訳では 1 つの~listに集約した上で，各`遊休~callback$の`稼働-可能か$により管理する。 そうした方がずっと簡潔に記述できるので。 】
◎ 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. - `遊休~callback識別子@ ⇒ 整数。 初期~時は 0 になるモノトスル。 ◎ An idle callback identifier, which is a number which MUST initially be zero.
4.1. `requestIdleCallback()^m ~method
`requestIdleCallback(callback, options)@m ~method~手続きは： ◎ When requestIdleCallback(callback, options) is invoked with a given IdleRequestCallback and optional IdleRequestOptions, the user agent MUST run the following steps:
- コレの`遊休~callback識別子$ ~INCBY 1 ◎ Let window be this Window object. ◎ Increment the window's idle callback identifier by one.
- %~handle ~LET コレの`遊休~callback識別子$の値 ◎ Let handle be the current value of window's idle callback identifier.
- コレの`遊休~callback~list$に，次のように設定された新たな`遊休~callback$を付加する ⇒＃ `~callback$ ~SET %callback, `~handle$ ~SET %~handle ◎ Push callback to the end of window's list of idle request callbacks, associated with handle.
-
~RET %~handle — ただし、以降の手続きも非同期に継続する。 ◎ Return handle and then continue running this algorithm asynchronously.
注記： 以降，手続きは並列的に走るが、 任意選択な `timeout^m ~memberが供されていれば， `setTimeout()^m に似た~timerも~queueする。 ここからは，遊休~callbackと~timeout~callbackの競争になり、 先に~scheduleされた方がもう片方 （例えば，遊休~callbackが先なら、~timeout~callbackの方） を取消すことになる。 ◎ The following steps run in parallel and queue a timer similar to setTimeout() if the optional timeout property is provided. From here, the idle and timeout callbacks are raced and cancel each other—e.g. if the idle callback is scheduled first, then it cancels the timeout callback, and vice versa.
-
~IF［ %options に `timeout$m ~memberは在る ］~AND［ その値 ~GT 0 ］： ◎ If the timeout property is present in options and has a positive value:
- %~timeout ~LET 現在の時刻 ~PLUS ( `timeout^m ~memberの値を~milli秒数として解釈した結果 ) ◎ ↓
- ［ 現在の時刻 ~GTE %~timeout ］になるまで待機する ◎ Wait for timeout milliseconds.
- ~IF［ この~algoの他の呼出nにて，この~algoの中で待機しているもののうち，［ そこでの %~timeout ~LT この %~timeout ］なるものがある ⇒ それらすべてが この~algoを完了するまで待機する ◎ Wait until all invocations of this algorithm, whose timeout added to their posted time occurred before this one's, have completed.
-
任意選択で ⇒ ~UAが定義する時間だけ更に待機する ◎ Optionally, wait a further user-agent defined length of time.
注記： この段には、［ 機器の電力消費を最適化する必要に応じて，~timeoutを~~延長する ］ことを~UAに許容することが意図される。 例えば，~timerの粒度を抑制するような節電~modeを備える処理器も中にはある — そのような~platformでは、 ~UAは，より正確aな非~節電~modeを利用することを要求する代わりに， この~scheduleに収まるよう~timerを遅くできる。 ◎ This is intended to allow user agents to pad timeouts as needed to optimise the power usage of the device. For example, some processors have a low-power mode where the granularity of timers is reduced; on such platforms, user agents can slow timers down to fit this schedule instead of requiring the processor to use the more accurate mode with its associated higher power usage.
-
`~taskを~queueする$( `遊休task~task~source$, 次の手続き )
手続きは ⇒ `~timeoutした遊休~callbackを呼出す$( コレ, %~handle )◎ Queue a task on the queue associated with the idle-task task source, which performs the invoke idle callback timeout algorithm, passing handle and window as arguments.
注記： `requestIdleCallback()$m は、［ 単独の`遊休~期間$~内に実行されることになる，~callbackの一回の~call ］のみを~scheduleする。 その~callbackは， %刻限 までに自身の作業を完了できないならば、 再度 `requestIdleCallback()$m を~callした上で （これは，~callback自身の中で行える）， 制御を即時に`~event~loop$に返して、 自身の~taskを継続するための未来の~callを~scheduleするべきである。 ◎ requestIdleCallback() only schedules a single callback, which will be executed during a single idle period. If the callback cannot complete its work before the given deadline then it should call requestIdleCallback() again (which may be done from within the callback) to schedule a future callback for the continuation of its task, and exit immediately to return control back to the event loop.
4.2. `cancelIdleCallback()^m ~method
この~methodは、 以前に行った`遊休~callback$を~scheduleする要請を取消す。 ◎ The cancelIdleCallback() method is used to cancel a previously made request to schedule an idle callback.＼
`cancelIdleCallback(handle)@m ~method~手続きは： ◎ When cancelIdleCallback(handle) is invoked, the user agent MUST run the following steps:
- %遊休~callback~list ~LET コレの`遊休~callback~list$ ◎ Let window be this Window object.
- ~IF［ %遊休~callback~list 内に［ `~handle$ ~EQ %~handle ］なる`遊休~callback$はある ］ ⇒ %遊休~callback~list から その`遊休~callback$を除去する ◎ Find the entry in either the window's list of idle request callbacks or list of runnable idle callbacks that is associated with the value handle. ◎ If there is such an entry, remove it from both window's list of idle request callbacks and the list of runnable idle callbacks.
注記： `cancelIdleCallback()$m は、 `稼働-可能か$どうかにかかわらず， `遊休~callback~list$から`遊休~callback$を除去する。 ◎ cancelIdleCallback might be invoked for an entry in window's list of idle request callbacks or the list of runnable idle callbacks. In either case the entry should be removed from the list so that the callback does not run.
4.3. `IdleDeadline^I ~interface
各 `IdleDeadline$I ~objには、 `刻限~時刻を取得する~algo@ が結付けられる。 それは、 `DOMHighResTimeStamp$I 値を返す~algoであり， 初期~時は 0 を返す~algoとする。 その結果は、刻限の絶対的な時刻 — すなわち，`時刻起点$から刻限までの時間~差 — を表現する。 ◎ Each IdleDeadline has an associated get deadline time algorithm, which returns a DOMHighResTimeStamp representing the absolute time in milliseconds of the deadline. The deadline is initially set to return zero.
`timeRemaining()@m ~method~手続きは： ◎ When the timeRemaining() method is invoked on an IdleDeadline object it MUST＼ ↓return the remaining duration before the deadline expires as a DOMHighResTimeStamp, which SHOULD be enough to allow measurement while preventing timing attack - see "Privacy and Security" section of [HR-TIME]. This value is calculated by performing the following steps:
- %今 ~LET `現在の高分解能~時刻$() ◎ Let now be a DOMHighResTimeStamp representing current high resolution time in milliseconds.
- %刻限 ~LET コレの`刻限~時刻を取得する~algo$() ◎ Let deadline be the result of calling IdleDeadline's get deadline time algorithm.
- ~RET ( %刻限 ~MINUS %今 ) を 0 以上に切り上げた結果 ◎ Let timeRemaining be deadline - now. ◎ If timeRemaining is negative, set it to 0. ◎ Return timeRemaining.
この~methodは、 %刻限 までの残り時間を表現する `DOMHighResTimeStamp$I 値を返す。 結果の正確度は、 測定は許容しつつ，計時~攻撃を防止するに十分な~~程度に抑えるベキである （ `HR-TIME-2$r § ~securityの考慮点を見よ）。 ◎ ↑
各 `IdleDeadline$I ~objには、 `~timeoutか@ 【！原文では 単に “~timeout” 】 が結付けられる。 それは、真偽値であり，初期~時は ~F とする。 ◎ Each IdleDeadline has an associated timeout, which is initially false.＼
`didTimeout@m 取得子~手続きは ⇒ ~RET コレの`~timeoutか$ ◎ The didTimeout getter MUST return timeout.
注記： `~timeoutした遊休~callbackを呼出す$~algoは、 ~callbackの登録-時に渡された `IdleRequestOptions$I の `timeout^m 値を超過したときには、 `~timeoutか$を ~T に設定して，~callbackが遊休~期間の外側で実行されていることを指示する。 ◎ The invoke idle callback timeout algorithm sets timeout to true to specify that the callback is being executed outside an idle period, due to it having exceeded the value of the IdleRequestOptions's timeout property which was passed when the callback was registered.
5. 処理~model
5.X. 遊休~callback
【 ~modelを明確かつ簡潔に記述するため、 この訳では，以下の各種~用語／~algoを導入する。 】
各 `遊休~callback@ は、次に挙げるものからなる：
- `~callback@
- ~scheduleするよう要請された~callback関数。
- `~handle@
- この遊休~callbackを`遊休~callback~list$内で一意に識別する整数。
- `稼働-可能か@
- 真偽値 — 初期~時は ~F とする。 ~F の間は、 次回の遊休~期間まで，`~callback$の~callは先送りされる。
`遊休~刻限を作成して遊休~callbackを呼出す@ ときは、所与の ( `遊休~callback$ %遊休~callback, `DOMHighResTimeStamp$I を返す~algo %刻限を取得する, 真偽値 %~timeoutか ) に対し，次を走らす：
- %遊休~刻限 ~LET 新たな `IdleDeadline$I ~obj
- %遊休~刻限 の ⇒＃ `刻限~時刻を取得する~algo$ ~SET %刻限を取得する, `~timeoutか$ ~SET %~timeoutか
-
%遊休~刻限 を引数に %遊休~callback の`~callback$を~callする†
この段にて~scriptから例外が投出されたときは、 ~catchして ⇒ その`~errorを報告する$
【† これは、`~callback関数を呼出す$を利用するよう，もっと精緻化する必要があろう。 】
5.1. 遊休~期間を開始する~algo
`遊休~期間を開始する@ ときは、 所与の ( `Window$I %window, `DOMHighResTimeStamp$I を返す~algo %刻限を取得する ) に対し，次を走らす： ◎ To start an idle period given Window window and getDeadline, an algorithm that returns a DOMHighResTimeStamp: [HR-TIME]
注記： この~algoは，［ ~event~loop処理~modelにおいて，~event~loopは他でもない遊休~中にあるものと決定されたとき ］に~callされる。 ◎ The algorithm is called by the event loop processing model when it determines that the event loop is otherwise idle.
-
任意選択で ⇒ ~IF［ 遊休~期間は遅延するべきと決定された ］ ⇒ ~RET ◎ Optionally, if the user agent determines the idle period should be delayed, return from this algorithm.
注記： これには、 ~UAが，機器の電力消費を最適化するために［ 必要に応じて，遊休~期間を開始するのを遅延できるようにする ］ことが意図されている。 ［ `文書$の`可視性~状態$ ~EQ `hidden^l ］の下では、 ~UAは，文書に対し遊休~期間の生成を間引くこともできる — 例：遊休~期間が 10 秒ごとに一回になるよう制限するなど。 ◎ This is intended to allow user agents to delay the start of idle periods as needed to optimise the power usage of the device. For example, if the Document's visibility state is "hidden" then the user agent can throttle idle period generation, for example limiting the Document to one idle period every 10 seconds to optimize for power usage.
- %window の`遊休~callback~list$を成す ~EACH( %遊休~callback ) に対し ⇒ %遊休~callback の`稼働-可能か$ ~SET ~T ◎ Let pending_list be window's list of idle request callbacks. ◎ Let run_list be window's list of runnable idle callbacks. ◎ Append all entries from pending_list into run_list preserving order. ◎ Clear pending_list.
-
`~taskを~queueする$( `遊休task~task~source$, 次の手続き )
手続きは ⇒ `遊休~callbackを呼出す$( %window, %刻限を取得する )◎ Queue a task on the queue associated with the idle-task task source, which performs the steps defined in the invoke idle callbacks algorithm with window and getDeadline as parameters.
これらの`~task$の`~task~source$は、 `遊休task~task~source@ とする。 【この段落は，なぜか原文から除去されたが、この用語を参照している箇所があるので，残してある。】
注記： 今から刻限まで 【上の~algoが呼出された時点から，~UAが［自身が遊休~中でなくなる］と予期する時点まで】 の時区間 を指して， `遊休~期間@ という。 どの `Window$I ~objにおいても、 ある時点で作動中な遊休~期間は，一つに限られる。 遊休~期間は、 ~UAが もはや遊休~中でないと決定した場合には，早期に終端し得る。 そうなった場合でも、 次回の遊休~期間は，刻限を過ぎるまで開始できない。 ◎ The time between now and the deadline is referred to as the idle period. There can only be one idle period active at a given time for any given Window. The idle period can end early if the user agent determines that it is no longer idle. If so, the next idle period cannot start until after deadline.
5.2. 遊休~callbackを呼出す~algo
`遊休~callbackを呼出す@ ときは、所与の ( `Window$I %window, `DOMHighResTimeStamp$I を返す~algo %刻限を取得する ) に対し，次を走らす： ◎ To invoke idle callbacks algorithm given Window window and getDeadline, an algorithm returning a DOMHighResTimeStamp: [HR-TIME].
- ~IF［ 高~優先度な作業が新たに~scheduleされたことに因り， 遊休~期間は早々に終端すべきと予見される ］ ⇒ ~RET ◎ If the user-agent believes it should end the idle period early due to newly scheduled high-priority work, return from the algorithm.
- ~IF［ 現在の時刻 ~GTE %刻限を取得する() ］ ⇒ ~RET ◎ If now is less than the result of calling getDeadline and＼
- %遊休~callback~list ~LET %window の`遊休~callback~list$ ◎ ↓
- %遊休~callback ~LET %遊休~callback~list 内に［ `稼働-可能か$ ~EQ ~T ］を満たす`遊休~callback$は［ 在るならば それらのうち最初のもの ／ 無いならば ε ］ ◎ ↓
- ~IF［ %遊休~callback ~EQ ε ］ ⇒ ~RET ◎ the window's list of runnable idle callbacks is not empty:
- %遊休~callback~list から %遊休~callback を除去する【！Pop】 ◎ Pop the top callback from window's list of runnable idle callbacks.
- `遊休~刻限を作成して遊休~callbackを呼出す$( %遊休~callback, %刻限を取得する, ~F ) ◎ Let deadlineArg be a new IdleDeadline whose is getDeadline. ◎ Call callback with deadlineArg as its argument. If an uncaught runtime script error occurs, then report the exception.
-
~IF［ %遊休~callback~list 内に［ `稼働-可能か$ ~EQ ~T ］を満たす`遊休~callback$は在る ］ ⇒ `~taskを~queueする$( 【`遊休task~task~source$】, 次の手続き )
手続きは ⇒ `遊休~callbackを呼出す$( %window, %刻限を取得する )◎ If window's list of runnable idle callbacks is not empty, queue a task which performs the steps in the invoke idle callbacks algorithm with getDeadline and window as a parameters and return from this algorithm
注記： ~UAは、刻限がまだ来ていなくても， 上の~algoの最初の段で終わらすものと裁定して 遊休~期間を早々に終端させれる。 例えば~UAは、 より優先度の高い稼働-可能な作業があれば，そう裁定してもヨイ。 ◎ The user agent is free to end an idle period early, even if deadline has not yet occurred, by deciding return from the algorithm in step 1. For example, the user agent may decide to do this if it determines that higher priority work has become runnable.
5.3. ~timeoutした遊休~callbackを呼出す~algo
`~timeoutした遊休~callbackを呼出す@ ときは、所与の ( %window, %~handle ) に対し，次を走らす： ◎ The invoke idle callback timeout algorithm:
- %遊休~callback ~LET %window の`遊休~callback~list$内に［ `~handle$ ~EQ %~handle ］を満たす`遊休~callback$は［ 在るならば それ ／ 無いならば ε ］ ◎ Let callback be the result of finding the entry in window's list of idle request callbacks or the list of runnable idle callbacks that is associated with the value given by the handle argument passed to the algorithm.
- ~IF［ %遊休~callback ~EQ ε ］ ⇒ ~RET ◎ If callback is not undefined:
- %window の`遊休~callback~list$から %遊休~callback を除去する ◎ Remove callback from both window's list of idle request callbacks and the list of runnable idle callbacks.
- %今 ~LET 現在の時刻 ◎ Let now be the current time.
- %刻限を取得する ~LET %今 を返す~algo ◎ ↓
- `遊休~刻限を作成して遊休~callbackを呼出す$( %遊休~callback, %刻限を取得する, ~T ) ◎ Let deadlineArg be a new IdleDeadline. Set the get deadline time algorithm associated with deadlineArg to an algorithm returning now and set the timeout associated with deadlineArg to true. ◎ Call callback with deadlineArg as its argument. If an uncaught runtime script error occurs, then report the exception.
6. ~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から返される時間の分解能は， `非同一-生成元~能力は隔離されるか？$enVに基づいて`粗化する$ベキである — この~APIが［ ~webに公開される他の~timerにより公開されるもの ］を超える情報を公開しないことを確保するよう。 `HR-TIME$r ◎ To mitigate cache and statistical fingerprinting attacks, the resolution of the time estimates returned by the IdleDeadline interface should be coarsened based on cross-origin isolated capability to ensure this API is not exposing more information than what's exposed by other web-exposed timers. [HR-TIME]
7. ~securityの考慮点
TBD【 `To Be Determined^en （未決定）】
謝辞
この仕様に貢献された次の方々に： ◎ The editors would like to thank the following people for contributing to this specification:
Sami Kyostila, Alex Clarke, Boris Zbarsky, Marcos Caceres, Jonas Sicking, Robert O'Callahan, David Baron, Todd Reifsteck, Tobin Titus, Elliott Sprehn, Tetsuharu OHZEKI, Lon Ingram, Domenic Denicola, Philippe Le Hegaret and Anne van Kesteren.