DevTools: show impl-site frames upon fling / accelerated animations |
||
Issue descriptionWe've historically shown main frames when main thread was invalidating. Unfortunately, that ends up with us showing 3fps while the scrolling is absolutely smooth and users no longer trust the trace. It seems like it would be more practical to show impl-side frames at least for fling gestures and accelerated animations, while still penalizing them for the long running tasks on the responsiveness side. note from elliott: """I wonder if we could show the percent of the viewport that is checkerboards when scrolling. Perhaps we can consider that as a future feature enhancement."""
,
Feb 7 2017
@tdresser: you should probbaly involve caseq@ into the discussion - we've gone through a number of iterations and ended up where we are, I'm sure he carries some important experience.
,
Feb 13 2017
Is there any documentation on the current plan for devtools? Our "processing user input" should probably include fling. I don't think that a single accelerated CSS animation should make us forgive a janky javascript driven touch drag though. You're right that we could just penalize them for long running tasks, but I think a single FPS measure which prioritizes the thread handling input will be easier to interpret.
,
Oct 4 2017
Bulk DevTools triage, closing low priority issues with no action plan. |
||
►
Sign in to add a comment |
||
Comment 1 by tdres...@chromium.org
, Feb 7 2017Our plan for the Frame Throughput metric is: Let duration(A) be the time reported to render frame A, and duration(A, THREAD) be the time to render frame A on thread THREAD. duration(A, THREAD) = SwapBuffers(A, THREAD) - BeginMainFrame(A, THREAD) If the page is animating on a single thread (ANIMATING_THREAD): duration(A) = duration(A, ANIMATING_THREAD) If the page is animating on both threads: If exactly one thread is processing user input (INPUT_THREAD): duration(A) = duration(A, INPUT_THREAD) Otherwise: duration(A) = max(duration(A, MAIN), duration(A, COMPOSITOR)) https://docs.google.com/document/d/1Bot91txCWZUstt32_BBLo-_HUsvOVn_L5yaI5xre2M0/edit#heading=h.vgw63b69t8jg I've also drafted up an overcomplicated approach to wrapping checkerboarding into a Frame Throughput metric here: https://docs.google.com/document/d/1Bot91txCWZUstt32_BBLo-_HUsvOVn_L5yaI5xre2M0/edit#heading=h.6q9vhqj5o1t3 I think it probably makes more sense to split it out though.