content/browser/scheduler/responsiveness/README

The classes in this folder estimate the responsiveness of Chrome by measuring
execution latency on the UI and IO threads of the browser process.

There are four types of work executed on the UI and IO threads.
1) Both the UI and IO threads can have tasks posted to them via the Task
   Scheduler [e.g. via content::BrowserThread::PostTask].
2) The UI thread processes native events directly from the message loop
   [NSEvents on macOS, MSGs on Windows, InputEvents on Android, XEvents on
   X11, etc.]
3) The IO thread's message pump processes IPCs by listening on data channels
   [e.g. fds] and waking up on available data.
4) The UI thread's message loop may process other platform-specific sources.

Execution latency is a measure of the duration between when a task or event is
scheduled or created, and when it finishes executing. We measure this for (1)
and (2) but not (3) and (4). More details:

1) Record TimeTicks::Now() when the event is scheduled and compare to
   TimeTicks::Now() when the event finishes execution.
2) All native events have a creation timestamp. Compare that to
   TimeTicks::Now() when the event finishes execution.
3) There's no good solution here, since the current wire format for IPCs does
   not record the time at which the IPC was written to the data channel. The
   time between reading from the data channel and finishing execution is
   typically small, as heavy tasks are supposed to be dispatched off the IO
   thread.
4) There is no consistent way to measure the execution latency of work that
   is neither a task nor an event. If individual sources prove to be
   a source of non-responsiveness, they will need to be addressed on a
   case-by-case basis.

Note: As long as there are any tasks or events queued, jank caused by (3) or
(4) will be accounted for, as it will show up as increased queueing time.

Design doc: https://docs.google.com/document/d/1vDSGFvJblh7yJ3U3RVB_7qZLubyfTbQdQjuN1GoUNkc/edit