Firefox/Features/50ms ASSERT: Difference between revisions

Firefox/Features/50ms ASSERT (view source)

Revision as of 11:07, 17 May 2011

205 bytes added , 17 May 2011

no edit summary

Dietrich

Confirmed users, Bureaucrats and Sysops emeriti

2,088

edits

@@ Line 7: / Line 7: @@
 <section begin="status" />
 |-
-| [[Firefox/Features/50ms_ASSERT|ASSERT when UI is delayed by more than 50ms]]
+| [[Firefox/Features/50ms_ASSERT|Understand when user interface feels laggy]]
 |{{StatusHealthy|status=Core instrumentation landed}}
 SDR: N || SIR: N
-| 2011-04-29
+| 2011-06-30
 | [[User:Dietrich|dietrich]]
 <section end="status" />
@@ Line 17: / Line 17: @@
 == Summary  ==
-Any time the user interface takes more than 50ms to respond to an action, it can appear sluggish to the user. To determine how often this happens, and what parts of our code are frequent offenders, we should add the ability to detect when the main-thread event loop is delayed by more than 50ms and log it as an ASSERT.
+Any time the user interface takes more than 50ms to respond to an action, the application will appear sluggish to the user. To determine how often this happens, and what parts of our code are frequent offenders, we should add the ability to detect when the main-thread event loop is delayed by more than 50ms and log it as an ASSERT.
-Update: There are two general scenarios in which UI is non-responsive. The first scenario is when a direct action by the user causes the app to be non-responsive. For example, a menu option with executes an action synchronously, and which takes >50ms to return. The second scenario is that some background action blocks the event loop for >50ms, causing the app to be generally non-responsive. We're working to get visibility into both scenarios.
+However, just an ASSERT does not tell developers *what caused* the delay. In order to be useful, we must provide the ability for developers to easily get information about what code is slow.
+There are generally two scenarios in which the browser UI is non-responsive.
+# When a direct action by the user causes the app to be non-responsive. For example, a menu option that executes an action synchronously, and takes >50ms to return.
+# When a background action blocks the event loop for >50ms, causing the whole app to be non-responsive.
+The goal of this project is to get developer visibility into both scenarios with easy-to-use tools.
 == Release Requirements  ==