0
222
VisualizaçõesInterpreting Dropped Frame In Chrome Dev Tools
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...
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?
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!
2 Respostas
Responde à pergunta0
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.
0
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.