Recall that I'm not interested in measuring all latency, only (for the time being) latency caused by JS code executing on the main thread or waiting for a CPOW. This simplifies a lot the implementation (when I execute JS code, I just need to check whether I'm currently dealing with a user-issued event), but unfortunately doesn't cover your use-case.
I'll be happy to brainstorm your use-case afterwards, but this sounds like an entirely different set of challenges. Cheers, David On 30/10/15 02:35, Ehsan Akhgari wrote: > Out of curiosity, how are you planning to measure input latency? Based > on event timestamps? > > The reason I'm asking is that with e10s, I sometimes see long (even > multi-second!) delays between for example clicking the new tab button, > or for the title of a new tab to appear after the tab being initially > painted) that are very visible to the user, and can't be detected that > way. I think it would be nice to come up with a set of user actions in > the primary UI and manually measure their delay based on the knowledge > that we have about the asynchronous nature of their implementation. > > Cheers, > Ehsan -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
