Re: Finding out if the main thread is currently animating
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
Re: Finding out if the main thread is currently animating
Note that I'm looking for a way to track this across the entire process, not a single document. I'd rather avoid having to track all documents (both XUL and HTML) in the process if I can find a simpler solution. On 30/10/15 01:18, Brian Birtles wrote: > For CSS animations/transitions (not including SVG SMIL animations), you > could use: > > document.timeline.getAnimations().some( > anim => anim.playState == 'running') > > (Soon to become just document.getAnimations()) > > We could likewise just check if the DocumentTimeline is observing the > refresh driver since we should stop doing that when CSS > animations/transitions are at rest. > > For rAF animations we could use the the js::NotifyAnimationActivity > information? Or else look for registered frame request callbacks? > > I think we could probably detect SVG SMIL animations too, if needed > (perhaps by exposing the mRegisteredWithRefreshDriver member of > nsSMILAnimationController although that might be too broad). -- 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
Re: Finding out if the main thread is currently animating
Yes, that's also my guess. I'd appreciate if someone could confirm that. Also, I haven't found a public API for this, so I'm digging in the source of the refresh driver, and I haven't found confirmation yet. Cheers, David On 30/10/15 02:33, Karl Tomlinson wrote: > David Rajchenbach-Teller writes: > I would guess that our main thread animations all run off a single > 60 Hz throttle, which I assume is the RefreshDriver. If that > throttle has no jobs scheduled to run, then I expect there are no > animations in progress. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- 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
Re: Finding out if the main thread is currently animating
I have posted an early patch on bug 1219145 that approximates "animating" to "is anyone listening for vsync". If anybody knowledgeable could take a look, I'd be grateful. Cheers, David On 30/10/15 02:33, Karl Tomlinson wrote: > David Rajchenbach-Teller writes: > >> To improve the Performance Stats API, I'm looking for a way to find out >> if we are currently animating something on the main thread. >> >> My definition of animating is pretty large, i.e. "will the user probably >> notice if some computation on the main thread lasts more than 32ms". >> >> Do we have a reliable way to do that? > > I would guess that our main thread animations all run off a single > 60 Hz throttle, which I assume is the RefreshDriver. If that > throttle has no jobs scheduled to run, then I expect there are no > animations in progress. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- 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
Re: Finding out if the main thread is currently animating
On 10/30/2015 2:35, Ehsan Akhgari wrote: On 2015-10-29 9:47 AM, David Rajchenbach-Teller 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. 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. This is exactly what I want Backtrack for (http://www.janbambas.cz/new-gecko-performance-tool-backtrack/). That tool will allow you to define "goal markers" instrumentation in the code that you get a list of and can track back to the original user interaction event and see where all you are blocked by what, across processes/threads/timers etc and isolate the blocking activity on "your goal path". Like a long async callback, but with added profiler data by side. I don't work on it right now as I'm occupied with NSec unfortunately... -hb- Cheers, Ehsan ___ 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
Re: Finding out if the main thread is currently animating
This sounds like a good idea. I'll see if I can get some time budgeted to help with this during Q1. Cheers, David On 30/10/15 15:09, Honza Bambas wrote: > This is exactly what I want Backtrack for > (http://www.janbambas.cz/new-gecko-performance-tool-backtrack/). That > tool will allow you to define "goal markers" instrumentation in the code > that you get a list of and can track back to the original user > interaction event and see where all you are blocked by what, across > processes/threads/timers etc and isolate the blocking activity on "your > goal path". Like a long async callback, but with added profiler data by > side. > > I don't work on it right now as I'm occupied with NSec unfortunately... > > -hb- > >> Cheers, >> Ehsan >> ___ >> 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 -- 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
Finding out if the main thread is currently animating
To improve the Performance Stats API, I'm looking for a way to find out if we are currently animating something on the main thread. My definition of animating is pretty large, i.e. "will the user probably notice if some computation on the main thread lasts more than 32ms". Do we have a reliable way to do that? -- 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
Re: Finding out if the main thread is currently animating
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 signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Finding out if the main thread is currently animating
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 On 10/29/2015 9:14 AM, David Rajchenbach-Teller wrote: To improve the Performance Stats API, I'm looking for a way to find out if we are currently animating something on the main thread. My definition of animating is pretty large, i.e. "will the user probably notice if some computation on the main thread lasts more than 32ms". Do we have a reliable way to do that? ___ 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
Re: Finding out if the main thread is currently animating
On 29/10/15 16:32, Benoit Girard wrote: > 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. Thanks. However, I'm not really looking for a detector, only a flag that will let me prune false positives. The Performance Stats API already detects [a subset of] lag, and the Addon Watcher informs the user when this lag is attributed to an add-on. Experience shows, however, that it regularly informs the user of invisible lag. In particular, Jetpack causes a CPOW when we're focusing Firefox, even if this has no impact on the user, AdBlock slows down some parts of loading, even if it generally makes loading faster on the whole, etc. While the event loop is not serviced as well as usual, from the point of view of the user, these are false positives. Hence my quest for a way to determine whether the main thread is currently in a jank-critical section (user-interaction or animation). Note that there are secondary applications to this, e.g. bug 1178972. Cheers, David -- 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
Re: Finding out if the main thread is currently animating
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
Re: Finding out if the main thread is currently animating
On 2015/10/30 0:57, David Rajchenbach-Teller wrote: On 29/10/15 16:32, Benoit Girard wrote: 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. Thanks. However, I'm not really looking for a detector, only a flag that will let me prune false positives. For CSS animations/transitions (not including SVG SMIL animations), you could use: document.timeline.getAnimations().some( anim => anim.playState == 'running') (Soon to become just document.getAnimations()) We could likewise just check if the DocumentTimeline is observing the refresh driver since we should stop doing that when CSS animations/transitions are at rest. For rAF animations we could use the the js::NotifyAnimationActivity information? Or else look for registered frame request callbacks? I think we could probably detect SVG SMIL animations too, if needed (perhaps by exposing the mRegisteredWithRefreshDriver member of nsSMILAnimationController although that might be too broad). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Finding out if the main thread is currently animating
David Rajchenbach-Teller writes: > To improve the Performance Stats API, I'm looking for a way to find out > if we are currently animating something on the main thread. > > My definition of animating is pretty large, i.e. "will the user probably > notice if some computation on the main thread lasts more than 32ms". > > Do we have a reliable way to do that? I would guess that our main thread animations all run off a single 60 Hz throttle, which I assume is the RefreshDriver. If that throttle has no jobs scheduled to run, then I expect there are no animations in progress. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Finding out if the main thread is currently animating
On 2015-10-29 9:47 AM, David Rajchenbach-Teller 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. 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
