We've explored several different ways of measuring this. Several of these are in the tree. Generally what I have found the most useful is to measure how we're servicing the content' main thread. This measurement is great because its measures how responsive Firefox is not only for scrolling/animations but nearly all use cases like typing latency.
There's EventTracer.h which is our best general responsiveness measurement at the moment. However it only traces the event loop up to each 20ms so it's a laggy indicator. On Thu, Oct 29, 2015 at 9:47 AM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > The main thread of the current chrome/content process. > > Indeed, animations are one of my two use cases, the other one being > user-input latency, but I'm almost sure I know how to deal with the latter. > > Cheers, > David > > > On 29/10/15 14:32, Benjamin Smedberg wrote: > > On the main thread of which process? > > > > Please consider non-"animation" use-cases. In particular, users do > > notice the latency of typing into edit boxes as much as anything else. > > So let's make sure that editing latency triggers this as much as a > > current animation. > > > > --BDS > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
