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