rqt_plot: Add button to clear the history without clearing the topics

[jbohren]

Currently, if rqt_plot has been running for a while, it gets very slow. The only fix for this is to clear out the history and topics. It would be great if there was a button that only cleared the history.

[trainman419]

+1

I would like to see the button next to Pause clear the history, and a separate option on the - menu that removes all topics.

[trainman419]

Side note: the QwtPlot backend doesn't have this problem because it maintains a fixed-size buffer of past data.

[adolfo-rt]

What I'd really like to see here is a configurable buffer length, like rxplot used to have (the -b argument I couldn't live without). A 'clear history' button still requires periodic human intervention which is undesired.

Side note: the QwtPlot backend doesn't have this problem because it maintains a fixed-size buffer of past data.

The bad thing about this backend is that AFAIK it does not properly handle message timestamps.

[DorianScholz]

Have you tried out the pyqtgraph backend? It's plotting performance is nearly as good as qwtplot and it handles timestamps. But I do not know how well it's performance degrades over time. Please let me know.
Nevertheless I'm all for changing the button next to pause to act as "clear history" and adding a "clear all topics" to the "-" button.

[adolfo-rt]

Have you tried out the pyqtgraph backend?

Yes, the refresh rate also degrades over time. I fired rqt_plot with the pyqtgraph backend and performed two tests on topic data that is being published at 50Hz:

• Display only one topic field. After 30min the slowdown is noticeable, but tolerable.
• Display 10 topic fields. After 30min, the slowdown is very significant, the refresh rate drops to ~1Hz.

[DorianScholz]

Thanks for the tests.
I think the best option then is to limit the buffer length in the update_values method of the plotting backends.
As @adolfo-rt said it would be desirable to make this limit configurable, e.g. in the configuration dialog.

[adolfo-rt]

How much dev overhead do you think it would take to keep a specified buffer size instead of (or complementary to) the single-shot clearing proposed in #245?. For rqt_plot, I imagine buffer length management would take place whenever new data arrives, but I wonder how this fits within the more general effort that is taking place in rqt_common_plugins.

[trainman419]

I could probably do that with another day's work, but I have a couple of deadlines coming up and don't have much time to spend on this in the next few weeks.

[adolfo-rt]

If you could sketch the general idea of what needs to be changed and where, I might give it a go. I'm not familiar with the codebase, and a good initial condition would make things go faster.

[trainman419]

In rqt_plot/src/rqt_plot/data_plot/__init__.py you'll want to modify the DataPlot class so that it limits the internal buffer size.

You'll also want to add an option to change the buffer size as part of the doSettingsDialog method.

Since the DataPlot is used from more than one place, and not all of them make sense to set a limit on the buffer size, there should probably be a way to disable the buffer size option completely. For example, the new rqt_bag plotting plugin uses the DataPlot widget, and limiting the internal buffer size there would not be a good idea.

[adolfo-rt]

Thanks @trainman419.

Since the DataPlot is used from more than one place, and not all of them make sense to set a limit on the buffer size, there should probably be a way to disable the buffer size option completely.

Exactly. I want to keep the larger picture in mind as to not affect negatively some DataPlot usecases in favor of others. I'll let you know what comes out of this.

[ablasdel]

closing as resolved due to merging of #245