Confirmed users
130
edits
Quantum/DOM: Difference between revisions
added FAQ from bevis
Wmccloskey (talk | contribs) (runnable naming convention) |
Wmccloskey (talk | contribs) (added FAQ from bevis) |
||
| Line 3: | Line 3: | ||
The goal of the Quantum DOM project is to eliminate jank caused by background tabs. One of the main ways we intend to do this is to run each tab in its own cooperatively scheduled thread. If a runnable on a background thread takes too long to run, then we will pause its execution and switch to a different thread. To do this correctly, we need to guarantee that web pages never observe a change in behavior. For example, it would be bad if we paused a runnable R1 and then allowed another runnable R2 from the same page to see that R1 had started but not yet finished. | The goal of the Quantum DOM project is to eliminate jank caused by background tabs. One of the main ways we intend to do this is to run each tab in its own cooperatively scheduled thread. If a runnable on a background thread takes too long to run, then we will pause its execution and switch to a different thread. To do this correctly, we need to guarantee that web pages never observe a change in behavior. For example, it would be bad if we paused a runnable R1 and then allowed another runnable R2 from the same page to see that R1 had started but not yet finished. | ||
One of the biggest pieces of the project is to "label" runnables with the page that they're operating on. This page describes how to label runnables. | One of the biggest pieces of the project is to "label" runnables with the page that they're operating on. This page describes how to label runnables. Additional information can be found in [https://www.google.com/url?q=https%3A%2F%2Fwww.icloud.com%2Fkeynote%2F0hmu8sUZRot_9XJACva_hdnKA%23DocGroup%255FLabeling%255Fin%255FQuantum%255FDOM&sa=D&ust=1485337842756000&usg=AFQjCNGenIQ8lbsBV3ovOoxvwBgNcKKpdg the brownbag talk here]. | ||
= Concepts = | = Concepts = | ||
| Line 235: | Line 235: | ||
return promise.forget(); | return promise.forget(); | ||
} | } | ||
= FAQ = | |||
=== How do I specify a label for an nsITimer TimerCallback? === | |||
<b>A:</b> This can be done by <code>nsITimer::SetTarget(nsIEventTarget*)</code> combined with <code>EventTargetFor</code>. See the XMLHttpRequest example above. | |||
=== Will the <code>TaskCategory</code> be used for prioritizing in the future? === | |||
If it will, how can developers ensure that the ordering won't be a problem if tasks are labeled in different categories in current developing stage? | |||
<b>A:</b> It may be used for scheduling in the future. Generally, anything that's not marked as Other should come from some outside source (usually IPC, but also from a timer). In that case, we have a lot of freedom about when to schedule it. So there shouldn't be too many concerns about breaking things as long as people follow that rule. | |||
=== How should I start labeling? === | |||
Do I need to review every line that includes "Dispatch" or "nsITimer"? | |||
<b>A:</b> A list of good labeling bugs is linked off [https://bugzilla.mozilla.org/show_bug.cgi?id=labeling bug 1321812]. We will use telemetry to decide which runnables are most important, and updates will be posted to that bug. | |||
=== Do runnables need to be labeled in the main process? === | |||
<b>A:</b> No. Only content process runnables need to be labeled. But labeling other runnables won't break anything. | |||
=== What is the impact of leaving a runnable unlabeled? === | |||
<b>A:</b> Say the event queue contains these runnables: [F1, B1, F2, B2, F3]. Assume that the F runnables are for the foreground tab and the B runnables are for a background tab. Then we could run F1, F2, and F3 before we run any of the B runnables. That's good. | |||
However, say the event queue contains: [F1, B1, F2, B2, X, F3]. Assume that X is an unlabeled runnable dispatched using NS_DispatchToMainThread. We can run F1 and F2. However, before we can run F3, we need to run B1, B2, and X. That's bad. Why is that? | |||
Well, X could be an F runnable (so maybe X = F2.5). If we ran F1, F2, F3 before the other runnables, then we would run F's events out of order (since F3 would run before F2.5). Therefore we need to run X before we run F3. | |||
However, X might also be a B runnable (so X = B3). Because of that, we need to run B1 and B2 before we run X. In total, B1, B2, and X must run before F3. | |||
So if we find an unlabeled event X in the queue, we need to run all the events before it before we can run any event after it. However, if we label X as a SystemGroup runnable, then we know it has no effect on the F or the B tabs. So it's fine to run it whenever we want. Therefore we could run F1, F2, F3 before any other runnables. | |||