Currently, we compute expected queueing time across all renderer main threads, including all tasks.
We'd like to be able to split this up based on attributes of the task and frame.
What is the exact definition for the split EQT? I understand we would split the busy time according to the frame/task, but what about the idle time? If we're busy on a task on frame A, does this time count as idle time for the EQT calculation of frame B, or do we disregard altogether this time?
Let's talk about task type first, as it's clearer.
For the task split, overall EQT should be the sum of all task type specific EQTs, so we do need to count time spent on a task of type A as idle time for the EQT computation for tasks of types B & C.
The frame split is a bit less clear, as some frames will be in the background, and shouldn't be included. If there are multiple foreground frames, the behavior among foreground frames should be the same as it is for tasks - the time spent in frame A should count as idle time for frames B & C.
Ok, so for now I'll work under the assumption that Global_EQT = sum of EQT(task_type)s = sum of EQT(frame)s. We already discard the time spent while the renderer is backgrounded, and I don't know if we have a consensus on a way to determine if a specific frame is backgrounded or not.
Comment 1 by tdres...@chromium.org
, Jul 21 2017