Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Ideas about pin and new view features


On Wed, Dec 7, 2016 at 5:23 PM, Jonathan Rajotte Julien <> wrote:

It make this probably common use case easy for the user: If you create new CFV and RV instances and pin them to Trace B, then they are time-synchronized together, and with their corresponding trace event table

Not sure what is the use case here. Could you illustrate it ?

|  CFV-A  |  CFV-B  |
|  RV-A*  |  RV-B   |
|       CPUU-A*     |
| Trace A*| Trace B |

OK, I'm making this more complicated than my original use case so that we can foresee potential issues:

Above, (*) means the active trace and the views with (*) means they are unpinned and showing the active trace. The other views are pinned to their respective trace.

My base use case is that the user has cloned CFV and RV and pinned them to Trace B (on the 'right' side). Then when navigating in CFV-B, the window range of RV-B should follow. When selecting in CFV-B or RV-B the selection follows in CFV-B, RV-B and Trace B.

Incidentally CFV-A is pinned while RV-A* and CPUU-A* are unpinned, but since they are showing the same trace, their window range and selection should also follow.

If the user makes Trace B active, now he has RV-B* and RV-B showing the same thing, but the user has control, he could have pinned RV-A* to Trace A...

For the other use case of browsing two different areas of the same trace, you would for example open Trace A again and get a new instance (A') and then just replace (B) with (A') above.

I don't share or understand your concerns here. In the current implementation each trace has its own time range and selection. Those that overlap are synchronized automatically.  What is global is the current active trace. So views that show the global active trace can get that specific trace's time range and selection, it is not a random or undetermined (i.e. confusing) selection. You currently can have two trace editors opened side-by-side and they each have their own selection (if they do not overlap).

"If they do not overlap" is the major problem here. You start by saying: "In the current implementation each trace has its own time range and selection" but you follow with "if they overlap" you share the selection for both of them. What I'm having a problem with is that selection can influence trace context that do not belong to the active trace. It may or may not happen (intersect or not).

Yes of course selection in one trace can influence the trace context of another trace, that is the whole point of the time synchronization between traces.

In the absence of any user togglable option, this synchronization was always active. But when there's no overlap it's not really useful, otherwise you always end up at the beginning or end time for the other trace (as you noticed with the bug in the trace editor), so ignoring the external selection in that case was a good compromise.

But no point in dwelling on the past if we are going to now allow the user to control the synchronization between traces.
Let's hope this get resolved ASAP and we find a way toward showing multiple trace at the same time in multiple views. It might be just the graphical view but they are 98% of the reason users use trace compass otherwise they would be using Babeltrace (regarding ctf and lttng).

If we have an initial version with no time-synchronization of pinned views, I don't think it needs to be delayed while we figure out how to control and apply the trace synchronization.

So automatic trace synchronization is apparently not something you want, but you have to be open to the idea that for some users it might be the only reason they use the tool. They might have two custom text logs that create no graphical view whatsoever, they just want to open them both and browse them together, keeping the trace editors synchronized. They currently can do this without having to bother about experiments.

No it is not something I want when they are not under an experiment. What is the purpose of an experiment?

Initially the purpose of an experiment was to merge multiple traces into one chronologically, at a stage where there could only be one trace/experiment opened at a time. It's when support for multiple opened traces was added that time-synchronization of traces was implemented, to provide a similar functionality without needing to create experiments.

>From the user doc:

"An experiment consists in an arbitrary number of aggregated traces for purpose of correlation. In the degenerate case, an experiment can consist of a single trace. The experiment provides a unified, time-ordered stream of the individual trace events."

Seems like a good fit here. Maybe the experiment part of Trace Compass is missing some love ?

I hope they heard of vim, emacs and other text viewer that most probably do a better job than TC at having split view for text, they even support offset scroll binding these day!

Thanks for the feedback I guess.

Starting with the container might be the way to go here.

That's much more involved because all the views have to become viewers, and have their tool bar refactored.
>From a meeting this morning here at EfficiOS:

Let's say we draw the final form we would like:

Lots of missing scenario but most of them should work okai and we think it addresses most of your concern.

As you probably observed we share a common goal and maybe other aspects: a sort of container. Here a trace but could be a trace collection, notebook, workgroup. Interactions do change based on what is the container.
"Trace" limits the content to view showing information about the trace, same for experiment/trace collection. Notebook and workgroup could be more flexible and allow multiple views showing different traces data etc.

In all cases signals would be restricted to the container. The event table become another view.

Where does pin fit in this scenario? A pinned view inside the container would simply stay under the container and act on its own (time wise) under the container. How to deal with multi selections is an open question.
One solution is to allow selection inside a pinned view and all views not pinned sync to it (as usual). A selection made outside of pinned view (another pinned view or any view) would update the selection inside of
the pinned view but does not update the visual time range (for visual windows base view). You end up with always one selection.

So from this end goal what do we do now with the current proposed features.

Pin become a view state like filters and other view states. On trace change we simply fetch the previous state related to this view/trace tuple and if it was pinned simply populate the pin state (signal blocking etc.)
This allow user to have multiple views of the same type (Control flow view, resource view) on different visual time range etc. but does not allow comparison between traces.
It remove ambiguity regarding what belongs to what and would fit better in the end goal. It prevent us from exposing a feature to a user that will probably not be useful in the end.

Some nice ideas here. Let me try to understand and compare:

So here pin only refers to window-range synchronization of multiple views belonging to the same trace. It's not trace-pinning because trace change wouldn't affect a trace-pinned view anyways (so it wouldn't make sense for a view to have one trace-pin state per trace. It's not time-selection synchronization because you propose only one time selection per trace.

One advantage vs. my proposal is that you wouldn't need to open a second trace instance to view a different window range of the same trace.

Some of the nice things you might lose however vs. my proposal are:
- You can't simultaneously browse the trace events from two different regions, automatically following the selection in each region (you could split the trace editor in Eclipse but good luck scrolling to the right place in a table of millions of events...)
- You can't make two range selections in each region and compare the delta (simultaneously)
- You can't have two range-pinned views follow each other as you navigate in them. You'd need to add some kind of pin-group controls. In my proposal the trace instance *is* the pin group. This avoids altogether the need to have a separate control of range-pin state per view.


Back to the top