there should be option(configurable) to add the frame data to each span

[atulgpt]

Expected

In the slow rendering instrumentation, there should be option to add counts of slow_frame_count, frozen_frame_count and total_frame_count in each span(or names of spans can also be configurable).

So for a span like below(which starts between t1 and t2), it should add all the frame count, frozen frame count and slow frame count that happened between t1 and t2

            t1                  t2
             <-------------------> 
                       span 1

This could be really important in determining during which span user experience is getting deteriorated

[atulgpt]

Hi @breedx-splk will this repo up for this contribution I can create a PR for this feature?

[breedx-splk]

Hey @atulgpt thanks for bringing this up and sorry for the lag in responding.

As you can see here, the instrumentation currently wants to send an event to note when slow rendering happens. I'm not convinced that having the frame count data would be appropriate to put on spans...but there's no convention for any of that stuff yet.

Another thing to keep in mind is that there can always be multiple spans at the same time -- so a slow render doesn't necessarily "belong" to a given span. If you want to see where (in a user flow) the actual end user might have experienced the jank, then it's up to the backend to correlate the time of the jank event with the prior activity.

For now, I'm not convinced that we want to do this...but I'm happy to keep talking about it.

[github-actions]

This has been automatically marked as stale because it has been marked as needing author feedback and has not had any activity for 21 days. It will be closed automatically if there is no response from the author within 14 additional days from this comment.

[atulgpt]

Another thing to keep in mind is that there can always be multiple spans at the same time -- so a slow render doesn't necessarily "belong" to a given span. If you want to see where (in a user flow) the actual end user might have experienced the jank, then it's up to the backend to correlate the time of the jank event with the prior activity.

For now, I'm not convinced that we want to do this...but I'm happy to keep talking about it.

Hi @breedx-splk in case of mobile, will having thread id of the span help here to correlate the data? it's up to the backend to correlate the time of the jank event with the prior activity. here I am concerned, that how much processing power and then cost will be involved in correlating this in back-end? If somehow we can contextually do this at the user device then this will save cost on server side

[breedx-splk]

Hi @breedx-splk in case of mobile, will having thread id of the span help here to correlate the data?

I don't think so, because a span context isn't constrained to a single thread -- so that a single span could exist and be processed at least in part by multiple threads. This is especially true with asynchronous frameworks and thread pool executors, etc.

I'm still a little unclear on what this feature is hoping to accomplish. It seems like it is being designed to save some backend resources from doing correlation...because I think you should already have all the data available, right? That is, if your goal is to know what spans were impacted by jank, shouldn't you just be able to query all spans that started before but ended after your jank event timestamp? If you wanted to be really pedantic/accurate, you could also account for the jank durations, but that might be overkill for most apps?

I guess I still need more convincing that this is helpful and not just overcomplicating things.

[bidetofevil]

Another issue with simply doing with is that our jank detection counts dropped frames in intervals that do not match the life time of each span. While I can see it being useful for some spans, simply having a total doesn't tell you the story of how jank could have potentially affected it. Did it occur at the beginning, were they spread across the lifetime, or did it happen all in a cluster that forces the screen to freeze?

In terms of correlation, the jank events are associated with the same session as spans, so you can calculate their appearance within the span via a session (somewhat coarsely) already. This shouldn't take a lot of computing power, as that type of correlation is foundational to understanding what is going on via mobile telemetry.