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
