Update: r560283 accounts for transforms by doing coordinate mapping with GeometryMapper.  However, it might be better to track jank scores per transform space.  We should re-examine this idea once we have a better idea of how we're going to handle iframes.

Ping as it's getting stale.

I don't have any updates here, but I'd consider this low priority since we aren't seeing significant perf cost from JankTracker based on the benchmarks (see  issue 847252 ).

JankTracker has been at 50% dev/canary for a while and we don't see significant real-world perf impact.

It has also been in the field trial testing config and we have only seen one regression on the perf bots (issue 909795), and I've verified that this issue is not caused by JankTracker's use of GeometryMapper (https://pinpoint-dot-chromeperf.appspot.com/job/16a434e9140000).

I initially thought we might do something similar to this for iframes, which would argue for generalizing.  But we want a page-level UKM that aggregates jank scores from iframes, including OOPIFs.  Therefore this aggregation needs to happen in the browser process.  We are already plumbing jank scores into the browser for each frame separately.  It doesn't make sense to add a separate path to aggregate same-origin iframes on the Blink side.  So iframes aren't a good reason to track separate jank scores per transform space.

Based on the above analysis I am going to close this bug.