Re: [tracecompass-dev] Ideas about pin and new view features

[Patrick Tasse <patrick.tasse@xxxxxxxxx>]

Hi,

On Fri, Dec 9, 2016 at 4:27 PM, Jonathan Rajotte Julien <Jonathan.rajotte-julien@xxxxxxxxxxxx> wrote:

+---------+---------+
|  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:

Not sure I got all of this but let's say you have the notion of container (pick your poison here) how does this could be achieved (illustrate if you can).

The way I envisioned it was that the containers would be workbench parts that allowed dockable widgets to be organized in their layout. All the viewers inside would be linked to the same trace instance and time-synchronized in window range and selection together.

So you would need two containers to browse two different traces at the same time, or two containers to browse two regions of the same trace (using two different trace instances).

I would see them as editor parts, just an expansion of the current trace editor, but containing possibly more widgets than the single one it has today (the event table).

The existing views (e.g. Control Flow view) being converted to viewers could easily exist within the trace editor or their own views, unpinned to active trace or pinned to a specific trace. I mean that it would be easy to implement as views after they have been converted to viewers, but I'm not saying that we would necessarily want to allow that.

+-------------------+
|      CPUUV-A*     |
+---------+---------+
|  CFV-A  |         |

| ------- |  CFV-B  |

|  RV-A   |         |
| ------- | ------- +
| Trace A*| Trace B |
+---------+---------+

Above would be two containers, one for Trace A and one for Trace B, the container for Trace A is active, and the unpinned CPUUV is showing active Trace A.

CFV-A, RV-A and Trace A are time-synchronized together, by their trace instance. The trace instance lives or dies in accordance with its container's editor part.

A synchronization toggle control could determine if the different containers (trace instances) are time-synchronized together.

To browse another region of Trace A, open a new instance in its own editor container (replace B with A' above).

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.

I do agree here. But you understand that this (no time-synchronization of pinned views) imply that in the short term a user will not be able to compare graphical views between traces (same as of now).

No, I'm not sure I understand?

By 'this' I mean your current patch sets but without the navigation restrictions? So you could get a new view instance and pin it to a trace isolated from time-synchronization. You would be able to browse the trace manually.

By 'short term' I assume just until a following patch which would enable time-synchronization (of pinned views showing the same trace as the new window range or selection source?).

 

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.

What is the purpose of an experiment now ? Why is it still there if the use case is *covered* by opening multiple traces?

It allows the merging of traces into a single trace. Initially we thought of traces of different types or different sources, but we also later discovered the case of a trace that was split into multiple trace files for disk usage considerations, it merges back together nicely in an experiment.

There were also some features developed specifically with experiments in mind, like the trace synchronization (the feature that computes a time offset by algorithm based on matching trace events from different traces), and the VM analysis, I believe.

 

In a  scenario when container key are traces/experiement:
    Pin strictly concern window range update. View only show data from the container key -> the trace/experiment.

In a scenario when a container is simply a container for signals.
    Each view shows data from the trace it was under when opened from the project explorer (this could be a drag and drop mechanism). No possibility to change trace on a per view basis neither for the container since the container have no notion of traces/experiment.
    Pin, again, strictly concern window range update.

In both scenario, one selection per trace is a limitation regarding the external support for multi selection of other parts of TC. The easy example of this are the external analysis. Currently they always take the selection from the global context. If we allow multiple selections, it will required an easy way for both the external analysis and the user to identify which selection the user is interested in (e.g. drop down dialog with last selected selection etc.).
This is something that can be fixed.

I see the problem, whether you have multiple 'selection context' on same trace instance or single selection on multiple trace instances (of the same trace), which are you referring to when you click the single trace element in the Project Explorer (to run an analysis or open a dependent view)?

 

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...)

Two different regions of the same trace? or from multiple traces?

If the same trace, not sure why we could not. Depends on how we handle selection.
If we allow one selection only (per container), you should be able to open N control flow view pin M of them, move O of them and move the selection. If the selection is visible in the windows range it will get displayed.

I was referring only to the event table in the trace editor, if there is only one instance per trace.

 

If we allow multiple selection. I do agree It get tricky.

If for multiple (intersecting) traces and that the container key is a trace, it gets complicated and yes you will need to manual sync between each of them. Since that in my proposition there is no signal exchange between containers.

This is where the notion of a container as a signal group become interesting. Thing is that if there is no visual indicator of such group it is very confusing. The easy way would be a tab or something like it. Each view would need  a clear visual indicator of which trace they show data of.

- You can't make two range selections in each region and compare the delta (simultaneously)

What delta ? How can this be handled in your proposition (illustration)?

I just meant measuring two ranges simultaneously that wouldn't be possible if there was only one selection per trace (and only one trace instance).

I guess ultimately two trace instance of the same trace or two 'selection contexts' of the same instance could be the same thing, but maybe for backward compatibility and maybe it would be a simpler implementation if it's just another instance of ITmfTrace vs. every user now having to know about trace 'selection context'?

Patrick