Open Bug 1017055 Opened 5 years ago Updated 5 years ago

Add telemetry for GC/CC during UI animations to evaluate hinting usefulness

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

People

(Reporter: avih, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Following bug 1005253 - where CC timing changes affected TART (tab animations) numbers, it was suggested to maybe use a hinting system to try and prevent GC/CC during short (typically ~250ms) UI animations (regardless of TART - to hopefully improve several UI animations).

While deploying such hinting system would raise several different concerns (at the very least of being a slippery slope), in order to even consider it, Andrew suggested to add some telemetry probes to help us understand how much of an issue it is in practice (GC/CC during UI animations).

I know that it shouldn't be hard to have the start and end points of the animation at the code, but I'm not familiar enough with GC/CC to know how to measure how much* GC/CC we perform inside this duration.

* "much" also probably needs some definition - i.e. number of invocations? time spent? Jank caused? etc.

Of course, if anyone has pros/cons arguments for such a GC/CC hinting to be used for short UI animations, here would be a good place to raise them.

Andrew, do we have a good definition for "how much GC/CC happened in this period"? if yes, are there APIs we can use to come up with a number which reflects "how much"?
Blocks: 956068
See Also: 956068
(In reply to Avi Halachmi (:avih) from comment #0)
> * "much" also probably needs some definition - i.e. number of invocations?
> time spent? Jank caused? etc.

Of course, the actual issue we want to poll is how much GC/CC affects UI animation, but considering that it affected TART, it's likely that currently it also affects other UI animations if it happens to be triggered while animating.

Therefore unless we have a better one, the overlapping between UI animation and GC/CC would probably have a good correlation to UI animation disruptions from GC/CC, but this is not necessarily given - depending on implementations.
I think the CC completely hangs the main thread while running, so I think just checking on entry to the CC if we're running an animation would be enough.  Or maybe doing it on exit, when we know how long the CC took, would be better.
(In reply to Andrew McCreight [:mccr8] from comment #2)
> I think the CC completely hangs the main thread while running

Would this disrupt off main thread animations?

> Or maybe doing it on exit, when we know how long the CC took, would
> be better.

So, if I understand correctly, you suggest to hook the telemetry code to the CC exit points, and then check if a UI animation happened between the CC start/end points?

I _think_ it would be easier to use the animation start/end points as hooks for this, and use them to query the GC/CC info. So maybe if GC/CC was entered at least once between the animation start/end points?
(In reply to Avi Halachmi (:avih) from comment #3)
> Would this disrupt off main thread animations?

As per our IRC conversation, Brian Birtles might be able to answer this. From what I can tell he has done a significant amount of work on OMTA.
Flags: needinfo?(birtles)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4)
> (In reply to Avi Halachmi (:avih) from comment #3)
> > Would this disrupt off main thread animations?
> 
> As per our IRC conversation, Brian Birtles might be able to answer this.
> From what I can tell he has done a significant amount of work on OMTA.

nrc knows this code best but if I understand what you're asking, then, no.

Off main thread animations are sent to the compositor when they start. If they have a delay, then they get sent at the end of the delay. After that they keep running on the compositor. When they reach the end they apply a forwards fill until they get removed from the compositor.

So, provided you waited until after animation had started, it wouldn't matter if the main thread got hung up. However, if your animation was *not* supposed to fill forwards and the main thread was still hung up at the end of the animation then you'd get an undesired forwards fill.

Nick, are there any other caveats to be aware of?
Flags: needinfo?(birtles) → needinfo?(ncameron)
Thanks, I think it contains the info which we were looking for.

After some clarification on IRC, it seems that OMTA smoothness (which is what we're interested in) will not get hurt by main thread hangs. The effect could be some extra lag to a final position in case it's not also the final step of the animation.

So we're left with only needing to add telemetry for CC/GC during main thread animations.
So, continuing from comment 3, Andrew:
- Do you think the telemetry hook should be at the exit from CC?
- Should we treat CC and GC differently? are they triggered together?
- Is there an existing API which I could use from the front-end code to quantify "how much UI-disturbing CC stuff" happened between two points in time? Maybe this would be enough: "Was CC performed (started/ended?) at least once?".

Or maybe there's some API to read when was the CC exit? This should also cover us, since as far as the UI is concerned, because it hangs the thread, if it exited during the animation, then it most probably also started during the same animation, right?
Flags: needinfo?(continuation)
(In reply to Avi Halachmi (:avih) from comment #7)
> So, continuing from comment 3, Andrew:
> - Do you think the telemetry hook should be at the exit from CC?
Maybe you want to do something like check in every CC slice if we interrupted an animation, however you do that, and then report once per CC if we interrupted at all?  Or maybe report the number of slices that interrupted?

> - Should we treat CC and GC differently? are they triggered together?
The GC and CC are totally separate, so different code would be required.

> - Is there an existing API which I could use from the front-end code to
> quantify "how much UI-disturbing CC stuff" happened between two points in
> time? Maybe this would be enough: "Was CC performed (started/ended?) at
> least once?".
There is not.  I guess some kind of interface could be added to clear and get the current count of the number of slices that have happened or something?  So you'd clear it when you start, and then check the count when you are done.  I'm not sure what sort of overhead that would have.

> Or maybe there's some API to read when was the CC exit? This should also
> cover us, since as far as the UI is concerned, because it hangs the thread,
> if it exited during the animation, then it most probably also started during
> the same animation, right?

Hmm, there isn't really anything like that.  It is a little weird now that CC is broken into slices.
Flags: needinfo?(continuation)
Depends on: 1019101
Depends on: 1019611
Sorry, this got lost in a sea of irrelevant bugmail. Re comment 5, that sounds correct. I can't recall any exceptions or caveats with that.
Flags: needinfo?(ncameron)
Depends on: 1046271
You need to log in before you can comment on or make changes to this bug.