Support interaction records in TBMv2 |
|||||
Issue descriptionThis is the bug to add support for interaction record in TBMv2. Design doc: bit.ly/ir-tbmv2 With the lessons we learned from interaction record in TBMv1, here are a few things that we would need for interaction record in TBMv2: 1) We need a way to output interaction records & parse them from the trace that can work cross processes boundary. The old interaction record only work if the "start interaction record" & "end interaction record" happen in the same renderer process. My proposal: we start interaction record by outputting a trace event whose name structure looks like "<name>/<flag>/<uuid>". We end the interaction record also by ouputting a similar trace event. In tracing/ code, we then create a interaction record by connecting those two through the shared uuid. e.g: A trace event named "Smooth Scroll/animation/343ef" & and another one named "Smooth Scroll/animation/343ef" will result in a single interaction record with ir.title = "Smooth Scroll" and ir.type = "animation" 2) Due to the fact that interaction record can go cross process boundaries, it's probably more similar to async event type than sync. 3) We might need to create interaction record not using chrome trace but through Telemetry trace. The reason is Chrome browser may not be alive yet at the time we need to create an ir (especially for some complex startup tests). 4) A set of interaction record flags(aka "types"). Tim: you have opinion about a good set of initial flags to support? I am thinking we gonna start with just 2 flags: "animation" and "loading"
,
May 29 2018
#1: Use slice metadata for flag & UID SGTM. I was thinking it's a bit hard in the case of relying on Chrome trace event (through performance.mark/measure), but as we move this to Telemetry trace, it's a lot easier to do so. I would avoid flow events for now, since slice metadata approach is simpler Re types: "animation", "input_driven_animation" and "loading" SGTM. I am also ok with not having start time of loading specified by trace event. Should we just name the the type "loading_end" to make this more explicit?
,
May 29 2018
loading_end SGTM. Ah, for mark & measure we might need to mash things into the name. Or rely on user timing L3, which lets you add metadata to mark's and measure's, but it's still behind a flag currently.
,
May 29 2018
#3: that's good to know. Though I think the current plan is to rely on Telemetry python trace events instead, so that we can create interaction record even before browser/ any renderer process starts.
,
May 29 2018
Were you thinking of extending the UserModelBuilder to find these markers and create AnimationExpectations and create/augment LoadExpectations? I would probably recommend that over defining another abstraction, pending a little thought about how it might affect other metrics.
,
May 29 2018
#5: yup. I was thinking that we should reuse UserModelBuilder. That would make it easier for complex interaction record types are created based on both IR event & chrome trace event (e.g: the input_driven_animation which we use start & end IR, then narrow down the time range to be exactly when the simulated user gestures are created & end).
,
May 30 2018
,
Sep 25
No one has taken this, lowering to P3...
,
Dec 18
Chatting with eyaich@ today, Ehsan already port the legacy interaction record system to TBMV2 (see https://chromium.googlesource.com/catapult.git/+/df56c1dae15e3d365ab4d62eb7f07522d70f64c5). So this bug is mostly would be improvement to the old IR system, and no longer a blocker to TBMv2 conversion
,
Jan 16
(6 days ago)
,
Jan 16
(6 days ago)
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tdres...@chromium.org
, May 29 2018