This boosts the timeline's accuracy and resilience for various cases such as where the introspector sends missing data, data with gaps, or where the user changes the state message duration setting. It removes some assumptions in timeline logic we'd made early on that we now know we can't rely on.
[x] If there are gaps between state messages' start and end times, make sure these are accounted for and visible in the timeline
[x] Where state messages have different lengths, account for this when using the timeline to select
[x] Align the red highlighted area precisely to the currently selected state's start and end time, with width reflecting this state message's width
[x] Align the label showing the currently selected time with the right hand edge (i.e. end time) of the current state
[x] Show milliseconds in the red timeline label, feintly (without this, it looks incorrectly aligned)
[x] Update how the first two states in a set of data are displayed so they are easier to select without showing misleading data (first state empty because we don't know how much traffic was specifically in that message, second one fading in because we know how much was at its end point but not its start point)
I've updated the 3 minute sample with one with some small example gaps between some states and changes in the state durations for validating this:
mcollina
commented
4 years ago
This boosts the timeline's accuracy and resilience for various cases such as where the introspector sends missing data, data with gaps, or where the user changes the state message duration setting. It removes some assumptions in timeline logic we'd made early on that we now know we can't rely on.
I've updated the 3 minute sample with one with some small example gaps between some states and changes in the state durations for validating this: