[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Selection-based WeightedTreeView
|
Hi Denis,
Thank you for your interest in Trace Compass. It's great to hear
about your needs in the WeightedTreeView. That was implemented
many years ago and not really revisited since... Any ideas or
contributions for improvements are more than welcome!
I'll add some comments inline below:
On 2021-05-31 10:31 a.m., tracecompass
developer discussions via tracecompass-dev wrote:
I however have two issues:
1) WeightedTreeView as it is provides a global pie chart
presenting data from the whole trace. I need to have it to
trigger a refresh on a range selection.
I was thinking of making a new WeightedTreeViewer class, and
overriding the updateElements method. But doing this doesn't
really seem possible without also modifying the WeightedTreeView
class, and maybe a few others.
Is there an easier way to achieve this that I don't see? The
way things look, I see two options:
- Modify WeightedTreeView/Viewer (and classes using them)
to accept a template, so behaviour can be overridden.
- Implement my own view, potentially reusing code from the
existing classes.
When we implemented the WeightedTreePieChartViewer, we took the
TmfPieChartViewer as a base, which uses a statistics model. At the
time (and still), it was too much work to make one single view
that takes a common model, so we copied it to display a weighted
tree. But the original statistics pie chart had 2 pies, a global
one and one for the selected time range. I recall starting with
pies too, hoping to see a selection one, but it turned out
confusing mentally to process/understand the results for the user,
so we just kept the global one.
But if you look at the flame graphs, we have 2 views, one of
which is global and the other for a selected range. The second one
inherits from the first and just adds a listener to the
TmfSelectionRangeUpdatedSignal to rebuild the view using the graph
from a time range instead of entire trace.
That may be another option, to add a WeightedTreeViewSel for a
selection that inherits the one that is there now. You will
probably need to add a method, similar to the FlameGraphView's
'#buildFlameGraph' to get the weighted tree for the selected. The
IWeightedTreeProvider already has a method to getSelection(start,
end), so that should be fairly easy-ish to refactor and that could
definitely be a great contribution to the current feature.
2) When implementing a IWeightedTreeProvider so it can be used
by the WeightedTreeView, the CallStackAanalysisListener adds the
Callstack/FlameGraph views which are not really interesting to
my use case. I've tried to see if I could de-register an output
to an analysis, however it doesn't look like this API exists.
Here, except renaming the interface to avoid the automatic
output registration, I don't really see how I could do this.
Indeed, the Flame Graphs are automatically added to all
IWeightedTreeProvider. Both views show the same data, with flame
graphs giving a nice quick visual representation of the whole
trees, for entire trace and selection. But if really you don't
want those views, your analysis module could simply override the
registerOutput method and not call super.registerOutput for the
outputs that you don't want!
Both of these issues says to me that maybe the handy-dandy
WeightedTreeView is not completely suited to my use case, and
maybe there is another path for me to take.
What advice could those familiar with those interfaces give me?
Without more details on your actual use case, I can't judge if
the WeightedTreeView is suited or not for it. I hope the hints I'm
giving you will help you figure it out! Don't hesitate to ask
further questions or comment on the issue! :D
Cheers,
Geneviève