Bug Description:
Statistics viewer pie charts sometimes do not display any data after opening a trace. Bug caused by the way TmfUiRefreshHandler coalesces UI elements
Inside of org.eclipse.tracecompass.internal.tmf.ui.viewers.statistics.TmfStatisticsViewer, whenever a trace is first opened, the method traceRangeUpdated is called. link
Inside of it, on first boot, two functions requestTimeRangeData and requestData are called. Inside the same file, we can see that these two are wrappers of a singular buildStatisticsTree method with a differing parameter in each case. One calls it with a isGlobal parameter set to true and the other to false. These calls then create jobs which are scheduled.
Inside of these org.eclipse.tracecompass.internal.tmf.ui.viewers.statistics.StatisticsUpdateJob , the statistics pie charts are refreshed with org.eclipse.tracecompass.internal.tmf.ui.viewers.statistics.TmfStatisticsViewer.refreshPieCharts link which itself calls two updates to the TmfUIRefreshHandler with the same pie chart source, one to set the viewer visible and the other to actually make the pie chart. This actual refreshing of the pie chart occurs in org.eclipse.tracecompass.internal.tmf.ui.viewers.piecharts.TmfPieChartViewer.refresh link Depending on whether the job was created with isGlobal parameter to true or false, this refresh will either make a "Selection" pie chart or a global pie chart. However, if the selection has less than two events selected, (which it does on opening a trace with the statistics view the first time), no pie charts will be shown.
For one source, the TmfUIRefreshHandler only keeps the most recent update request with a term that is defined as 'coalescing' in the repo link. Thus some requests for the pie chart viewer fall through without ever being done.
When opening a Statistics view, on certain occasions, the pie charts would not show (rare) and I analyzed the code to deduce that sometimes the two jobs were scheduled in a way where
-
1: The global pie chart is queued to be shown in the org.eclipse.tracecompass.tmf.ui.TmfUIRefreshHandler
-
2: Before the update for the global pie chart is shown, the selection pie chart, which is an empty pie chart (due to less than 2 events selected), is queued for updated which erases the global pie chart in the org.eclipse.tracecompass.tmf.ui.TmfUIRefreshHandler. Since there are less than two events selected, no data is shown where the pie chart would go.
This behaviour where two jobs are competing for the TmfUI, only occurs when opening a new trace. When selecting a window of events from the UI, the pie charts are updated through another function from org.eclipse.tracecompass.internal.tmf.ui.viewers.statistics.TmfStatisticsViewer. Instead of traceRangeUpdated, which makes two UpdateStatisticsJob, timeSynchUpdated is called which only calls one.
To note, within a single statistics job, there are two successive queueUpdate calls, meaning the first one will never be done. The queue Update that never gets enacted can be seen in the following definition of the refreshPieCharts link
setPieChartsVisible(moreThanOne);
TmfUiRefreshHandler.getInstance().queueUpdate(fPieChartViewer, () -> {
if (!viewerControl.isDisposed()) {
fPieChartViewer.refresh(refreshGlobal, refreshSelection);
}
expanding with the contents of setPieChartsVisible(moreThanOne)
private void setPieChartsVisible(final boolean visible) {
if (fPieChartViewer.isDisposed()) {
return;
}
TmfUiRefreshHandler.getInstance().queueUpdate(fPieChartViewer, () -> {
if (!fPieChartViewer.isDisposed()) {
fPieChartViewer.setVisible(visible);
fPieChartViewer.getParent().layout();
}
});
}
We can see there are two calls to queueUpdate with the same fPieChartViewer source, thus the setPieChartsVisible effectively does nothing.
Similarly, in traceRangeUpdated, why are there two request data functions if they eventually queue a UI update with the same source. One is bound to be removed no?
Any clarification would be greatly appreciated as I am relatively new to tracecompass. I could be interpreting these lines of code wrong and if so, please point it out.
Steps to Reproduce:
- Static Code Analysis
- Open a new trace with the statistics view open in the perspective over and over again until the problem arises.
Increased Statistics Pie Chart viewer robustness
Due to random scheduling by the OS, the choice for which job goes first and consequentially the order of the org.eclipse.tracecompass.internal.tmf.ui.viewers.piecharts.TmfPieChartViewer.refresh can make the "Selection Pie Chart" have priority even when it will end up making an empty pie chart (less than 2 event types chosen).
A proposed robustness increase is proposed in issue #412 and PR #413
Additional Information
- Operating System: Windows 11
- Trace Compass Version: 11.3
Bug Description:
Statistics viewer pie charts sometimes do not display any data after opening a trace. Bug caused by the way
TmfUiRefreshHandlercoalesces UI elementsInside of
org.eclipse.tracecompass.internal.tmf.ui.viewers.statistics.TmfStatisticsViewer, whenever a trace is first opened, the methodtraceRangeUpdatedis called. linkInside of it, on first boot, two functions
requestTimeRangeDataandrequestDataare called. Inside the same file, we can see that these two are wrappers of a singularbuildStatisticsTreemethod with a differing parameter in each case. One calls it with a isGlobal parameter set to true and the other to false. These calls then create jobs which are scheduled.Inside of these
org.eclipse.tracecompass.internal.tmf.ui.viewers.statistics.StatisticsUpdateJob, the statistics pie charts are refreshed withorg.eclipse.tracecompass.internal.tmf.ui.viewers.statistics.TmfStatisticsViewer.refreshPieChartslink which itself calls two updates to theTmfUIRefreshHandlerwith the same pie chart source, one to set the viewer visible and the other to actually make the pie chart. This actual refreshing of the pie chart occurs inorg.eclipse.tracecompass.internal.tmf.ui.viewers.piecharts.TmfPieChartViewer.refreshlink Depending on whether the job was created with isGlobal parameter to true or false, this refresh will either make a "Selection" pie chart or a global pie chart. However, if the selection has less than two events selected, (which it does on opening a trace with the statistics view the first time), no pie charts will be shown.For one source, the TmfUIRefreshHandler only keeps the most recent update request with a term that is defined as 'coalescing' in the repo link. Thus some requests for the pie chart viewer fall through without ever being done.
When opening a Statistics view, on certain occasions, the pie charts would not show (rare) and I analyzed the code to deduce that sometimes the two jobs were scheduled in a way where
1: The global pie chart is queued to be shown in the
org.eclipse.tracecompass.tmf.ui.TmfUIRefreshHandler2: Before the update for the global pie chart is shown, the selection pie chart, which is an empty pie chart (due to less than 2 events selected), is queued for updated which erases the global pie chart in the
org.eclipse.tracecompass.tmf.ui.TmfUIRefreshHandler. Since there are less than two events selected, no data is shown where the pie chart would go.This behaviour where two jobs are competing for the TmfUI, only occurs when opening a new trace. When selecting a window of events from the UI, the pie charts are updated through another function from
org.eclipse.tracecompass.internal.tmf.ui.viewers.statistics.TmfStatisticsViewer. Instead oftraceRangeUpdated, which makes twoUpdateStatisticsJob,timeSynchUpdatedis called which only calls one.To note, within a single statistics job, there are two successive queueUpdate calls, meaning the first one will never be done. The queue Update that never gets enacted can be seen in the following definition of the
refreshPieChartslinkexpanding with the contents of setPieChartsVisible(moreThanOne)
We can see there are two calls to queueUpdate with the same fPieChartViewer source, thus the
setPieChartsVisibleeffectively does nothing.Similarly, in
traceRangeUpdated, why are there two request data functions if they eventually queue a UI update with the same source. One is bound to be removed no?Any clarification would be greatly appreciated as I am relatively new to tracecompass. I could be interpreting these lines of code wrong and if so, please point it out.
Steps to Reproduce:
Increased Statistics Pie Chart viewer robustness
Due to random scheduling by the OS, the choice for which job goes first and consequentially the order of the
org.eclipse.tracecompass.internal.tmf.ui.viewers.piecharts.TmfPieChartViewer.refreshcan make the "Selection Pie Chart" have priority even when it will end up making an empty pie chart (less than 2 event types chosen).A proposed robustness increase is proposed in issue #412 and PR #413
Additional Information