[EPIC] Frames Delay

[philipphofmann]

Specification is here https://develop.sentry.dev/sdk/performance/frames-delay/.
Internal Notion SDK Roadmap Doc

Tasks

Beta Give feedback

1. Add frames delay for transactions and spans sentry-cocoa#3481
   4 of 4
   Platform: Cocoa +1
   
2. feat(perf): Add frames delay to mobile vitals sentry#61349
   Scope: Backend Scope: Frontend +2
3. Add frames delay develop#1153
   +0
4. [Starfish] Add frame delay for transactions and spans sentry-java#3099
   3 of 3
   Platform: Android Platform: Java +2
   

[shruthilayaj]

@philipphofmann Is there a reason why we'd want to capture this information the difference between expected frame render time and actual duration ie (300 - 16.67) instead of just frame duration if it exceeds expected render time? Also, do you know what duration profiles show for slow/frozen frame durations?

[philipphofmann]

Is there a reason why we'd want to capture this information the difference between expected frame render time and actual duration ie (300 - 16.67) instead of just frame duration if it exceeds expected render time?

Yes, because the frame rate can change at any moment. You could have 120 fps or 60 fps or even a lower rate. If we would send the frame duration we would also need to send the frame rate. We still can't send multiple values for spans and transactions, so we need to narrow it down to one value. If we would send only the frame duration, we don't include the frame rate. Frame delay tells you how much a frame was delayed, no matter the frame rate. It's also what the user perceives as a hitch in the UI. That's how I came up with the calculation.

Also, do you know what duration profiles show for slow/frozen frame durations?

Here is a sample transaction with slow and frozen frames and a profile.

[shruthilayaj]

I see - I was also thinking frame duration as a single metric (ie the total duration of your slow/frozen frames) but good point about the different frame rates. I think for the top level metric, Frame Delay makes sense - although we should also report a normalized version of this metric (like Apple's scroll hitch ratio).

Do the SDKs have access to the expected number of frame renders and frame rate @philipphofmann? That way we can calculate the total expected duration of frame renders and report a ratio like (frame delay in ms) / (total expected render time in s).

[philipphofmann]

Do the SDKs have access to the expected number of frame renders and frame rate @philipphofmann? That way we can calculate the total expected duration of frame renders and report a ratio like (frame delay in ms) / (total expected render time in s).

On iOS yes. We still trying to figure that out on Android, but I think yes @markushi and @stefanosiano?

[markushi]

On Android we could calculate the expected number of frames based on the last known frame rate, the last kown frame drawn timestamp and the span end timestamp. So yes, we can do that on Android!