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 2016-12-10 05:02 PM, Patrick Tasse wrote:

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.

As discussed in meat space. We agree on the "workbench parts that allowed dockable" part, less on what would be the signal key for synchronization (trace, parent workbench, etc.) and what would be allowed inside this container (widget linked to different trace, etc.).

A good start would be to decide what would be the signal key. For now, the obvious choice would be the trace object since most signal already carry it in a way or another.

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

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

As of today, if I remember, TC does not allow this?

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'?

Conclusion from the meat space interaction.

Regarding the current proposed patch set, two additional RFC patch set will be produced to evaluate the UX and functionality. Those will be based on the current patch set as of today. Implementation details regarding how to scope the feature in the code (TmfView wide feature, Interface, etc.) will be leaved for when we have a consensus on the UX.

The first one will allow user to navigate but will deactivate everything implicating selection. The view will be isolated regarding selection. No selection will be permitted inside the viewer and no selection indicator will exist for the pinned view. This allow the view to be completely isolated and will allow multiple view with different trace.

The second one will allow navigation and selection. Selection made inside the pinned view will propagate to other view and selection made by other view will be propagated to the pinned view. When pinned a control flow/resource view will not seek to show update of selection.



tracecompass-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Jonathan R. Julien

Back to the top