Interpreting Dropped Frame In Chrome Dev Tools
Asked Answered
S

3

47

I am looking for information on how to interpret the Chrome Dev Tools when it shows a dropped frame. The official docs don't seem to cover this or the Udacity course about request animation frames.

I have a webGL project (using Three.js) and I see the following in chrome dev tools when I'm animating - I am using requestAnimationFrame.

To be clear, I AM NOT asking how to fix my code, or what is wrong with my code. I am asking for help understanding what this is telling me, the code is irrelevant.

If anyone could suggest...

enter image description here

  1. From the above screenshot you can see that it's taking 15.7ms but warning there's a dropped frame. If I click on the task it seems to take 12ms, so wheres the additional 3.7 ms coming from? How can I find out, since my functions are all covered in the "task" portion?

  2. Is the green 1.0ms that is seen before the ref 15.7ms a frame? - Does that mean I'm firing a requestAnimationFrame but doing nothing? Since nothing is shown in the dev tools, how can I find out what is firing it?

EDIT. Here's a more extreme example I can get, as you can see its the same sort of thing though, my task actually took 9ms, but it says the frame was 82ms!

enter image description here

Swanhilda answered 31/3, 2021 at 9:48 Comment(4)
I remember googling it a few weeks ago and stumbling upon video related results. This "dropped frame" thing tripped me up again today so I'm glad you ask this on SO and hope someone from the Google team will read/answer it or that a proper documentation will be written. But I believe that a "dropped frame" is not a "bad" thing. It exists even for the simplest and most performant animation. It's like a drop of paint that has fallen on the screen. I also believe that the 3.7 ms is the time during which the GPU and the compositor are producing the result on the screen. No idea about 2. – Navigable
thanks for the comment, i cant find any decent information about this, so if any of the videos had anything remotely useful it would be great if you could link to them. – Swanhilda
I'm having similar issues, where renders dependent on scroll events, while scrolling on a mac trackpad, can delay the next frame indefinitely (until the scroll stops). For me, the frame times are identical (~16ms), but I get a long string of dropped frames during the scroll. No javascript runs during these dropped frames. It seems to be related to render load. Also, If I disable "threaded scrolling" in chrome, the situation improves considerably. – Tidy
I wish there were better docs about this sort of Chrome perf tools arcana! Unfortunately I suspect we're doomed to a life of guessing and "original research" 😭 – Tidy
O
11

I'm not from Google, not even an expert in DevTools, just pass by after reading a few lines of code in Chrome DevTools.

There are a few reasons why a frame is dropped, you can check at FrameDropReason.

But to understand what is the reason for the dropped frame, I don't find any better way other than reading the profiling JSON, which you may find something like this:

{"args":{"data":{"compositeFailed":8192,"unsupportedProperties":["background-color"]}},"cat":"blink.animations,devtools.timeline,benchmark,rail","id2":{"local":"0x3b08a0fb80"},"name":"Animation","ph":"n","pid":23024,"scope":"blink.animations,devtools.timeline,benchmark,rail","tid":259,"ts":71014192568},

Basically says the frame dropped by the compositor, because of unsupported CSS probs. More details on Compositor Failure reasons here.

It's also good to look into this issue which tracks the addition of Dropped Frame.

Again, I'm not entirely sure, just some hints for you to look into.

Outward answered 31/5, 2021 at 6:4 Comment(2)
thanks for the comment, I didn't know any of this. Unfortunately when I look at the JSON and search for compositeFailed i get.. {"args":{"data":{"compositeFailed":0}},"cat":"blink.animations,devtools.timeline,benchmark,rail","id2":{"local":"0xe9a65653d10"},"name":"Animation","ph":"n","pid":688,"scope":"blink.animations,devtools.timeline,benchmark,rail","tid":11828,"ts":329342225927}, which still doesn't tell me much (I don't think) – Swanhilda
hey, I just updated my answer with a link to Composite failure reasons. Basically, your log of compositeFailed: 0 says no composite failed, so you may want to search for other compositeFailed until you could find one with none zero. – Outward
N
1

This is only my personal interpretation.

Dropped frame

A "dropped frame" can occur even with very simple animation, but contrary to what I wrote in my above comment, it does not correspond to a frame that is actually rendered on the screen.

If you create a very simple Web Animation like opacity: [0, 1], created via CSS or JS, and record its performances via the corresponding panel in Chrome v90, you should see that 98% of the frames are green and 2% are red (dropped frames). Note that green and red frames can last more and sometimes less than 16.67 ms.

Also note that I believe there was even more red frames reported in Chrome v89 for this kind of animation.

The 3.7 ms after the animation task

This time seems to be used by the Graphic Process Unit to make the composition work, as denoted by the (green, ~1ms) GPU task right after the animation task. There's still 2.7 ms left without any explanation though.

Chrome DevTools seems not to be 100% reliable. It might be latency between GPU and CPU, or a missing information. If you record a simple animation for less than ~6 s, sometimes there is no information recorded at all! But I believe that measuring animation performances has always been hard and that Chrome is trying to improve it in its latest releases.

The 1 ms before the animation

I think this is the time taken by the browser to run the mandatory tasks before starting a new render cycle.

In summary, the terms "frame" and "fps" (frame per second) seems to be used in a way which is rather confusing to understand.

Navigable answered 19/4, 2021 at 6:31 Comment(0)
C
0

I am not a profiling expert, but I have been having this same issue. I have found the chrome://tracing feature to be useful to find out what is happening during the times when dropped frames seem to correlate with no active JS tasks.

Here is a screenshot of the Chrome Profile: Profile Note the dropped frames which seem to have no tasks or any activity at all to cause them

Here is a screenshot of the same trace (exported json and loaded into the tracing tool):enter image description here

This does not answer your question exactly, but by exporting the json and loading into the tracing tool you may be able to scroll thru to find the internal render pipeline functions that are taking up the bulk of your time during the dropped frames. My guess is that Chrome requires variable amounts of time for rendering after the JS tasks are finished.

The clue I've found is that the dropped frames seem to always correspond to a "LongAnimationFrame" item. I am looking into using the Chrome experimental LongAnimationFrame API to get further details:

https://www.debugbear.com/blog/long-animation-frames

My other guess is that the profiler does not list all function calls, an instead only shows ones which are sampled correctly. Maybe the sampling is done with some sort of downsampling. According to this thread there are some issues with the Chrome Profiler not showing all GPU work being done, so maybe take the profiler results with a grain of salt:

https://discourse.threejs.org/t/tons-of-idle-time-in-chrome-performance-profiler-but-still-low-framerate-how-do-i-read-these-results/13195/9

Chrome tracing: https://aras-p.info/blog/2017/01/23/Chrome-Tracing-as-Profiler-Frontend/ Chromium frame lifetime: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/life_of_a_frame.md

Complaisant answered 19/2 at 19:58 Comment(0)

© 2022 - 2024 β€” McMap. All rights reserved.