Re: [tracecompass-dev] Upcoming UI features

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

On 16-02-16 05:47 PM, Alexandre Montplaisir wrote:
> On 2016-02-16 10:57 AM, Matthew Khouzam wrote:
>> Hi All,
>>
>> We're developing some new views and revamping old ones in tracecompass,
>> I think we are at the point where we can seek feedback.
>>
>>
>> 1- Split the resources view into an Execution context view and an
>> Interrupts view.
>
> Hi Matthew,
>
> Modeling the IRQ information per CPU is important, as pointed out in
> bug 381497 [1]. However, it is also important to keep the "aggregate"
> information, because there are use cases that make heavy use of this
> (following the activity of one IRQ or one driver through the trace for
> example). There is a problem right now with our current model, because
> we don't split it per CPU. The new version should show something like
> this:
>
>   IRQ 1 ---[----][----][-----]
>
>   CPU 0 ---[----------]-------
>
>     CPU 1 ---------[-----------]


Yes, this is a bug, but I feel it didn't impede enough with the
experience to collect user feedback.

To go over the bug, I will work on this if this path is chosen, but I
want confirmation that this is the way to go before fixing a bug.

Can you comment on the look and feel of this asside from the bug? (I
know once you see it, you cannot unsee it).

We will worry about the model, or the choice of libs at this moment, it
will change immensely depending on user feedback.

If everyone says: This view should be split into SoftIRQ and IRQ, or we
should be able to do x-y-z... this is the kind of feedback I'm looking
for here.

>> 2- Show CPU usage for a given CPU
>>
>> 3- Follow thread
>
> This is another interesting topic. I have mentioned previously the
> idea of extending the TmfTraceContext to be able to hold additional
> information provided by analyses. Things like a "current selected
> thread" and a "current selected CPU" would be a perfect example. I see
> a patch [2] was posted to add signals indicating thread or CPU
> selection. This is pretty good, but it would also require a similar
> addition to the trace context, just like we do with time stamp and
> visible range selections. That way if a view is closed when a signal
> is sent, but opened later, it can still query what is the current
> thread/CPU it should show.
>
> Another thing to keep in mind: would it be possible to select multiple
> threads or CPU at once? That could be very useful too.

This is an idea I'm keeping for later, the concept of multiple selection
is easy from a model point of view, it's more from a clean UI point of
view that this becomes complicated.

A tip: always assume we have 256 cpu cores, 64 IRQ levels, 500 unique
syscalls and 30000 threads. This shows why it is difficult to work on
the UI side. Showing everything will drown the user, showing what is
selected is a nice heuristic IMO.

An Idea would be "Follow X"
and then, for another item "Follow Y"/"Add Y"/"Unfollow all"

Just an idea.

Thoughts?


Matthew