rqt_bag could display a loading bar for large bag files

[jbohren]

Right now, when loading large bagfiles (tens of gigabytes) rqt_bag just freezes, as do any other plugins loaded into the same ros gui. rqt_bag could use a background thread and signal updates to a status bar to show the progress of loading one of these bag files, which can take tens of minutes.

[130s]

Same as for many rqt plugins this is valid enhancement. When time allows, I'll add this by using a class in rqt_py_common.

[dirk-thomas]

Is this still a valid issue for you @jbohren? That it takes tens of minutes to load a bag file?

When I open a bagfile which is over 1 GB in size it takes just 0.17 seconds to load. So I would guess for even 50 GB the time should be only a few seconds.

[trainman419]

+1; this is an issue for me as well. I have a 1.7GB bag file that takes about a minute to load.

[trainman419]

Initial proof-of-concept in 3c19d58

[ablasdel]

Looking back on this there is actually a QProgressBar already in the UI that looks like it was implemented incorrectly (my bad). If you are looking at fixing this issue you might want to look at fixing or replacing that QProgressBar instead of adding a whole new Label to handle it.

[trainman419]

The trouble I had with using the existing QProgressBar is that the rosbag library doesn't actually give us a progress estimate when loading a bag file, so my first approximation simply adds yet another text field to display a message describing the state (and it's way too small for the intended use).

I'm open to other suggestions about how to improve or utilize the existing progress bar.

[ablasdel]

The progress bar is just wasted space since it doesn't (and seemingly has never) work properly please just use replace the QProgressbar widget with your new solution widget.

[trainman419]

The existing progress bar is used in a few places, I think during reindexing and when exporting a selected region of a bag file.

For reference, the old rxbag shows an empty window and displays a "loading [bagfile]..." message in the title bar when loading a large bag file.

[dirk-thomas]

Even when you don't have progress information you should use a progress bar.

[ablasdel]

I'm not sure what you mean here @dirk-thomas. What would be displayed on the progress bar if we don't have progress information available? Rough guess/estimate of time remaining? Or are you saying we should have the equivalent of a "spiny ball" just for feedback that the program is still doing work and not locked up?

When users see a progress bar they expect it to go from 0-100% and be done when it hits 100. If we can't do that I think it makes sense to use a different Widget to display the information we actually have.

[dirk-thomas]

Quote from http://qt-project.org/doc/qt-4.8/qprogressbar.html#details

If minimum and maximum both are set to 0, the bar shows a busy indicator instead of a percentage of steps. This is useful, for example, when ... unable to determine ...

[ablasdel]

Unsurprisingly Dirk is correct. Let's use the existing progress bar and set it to the busy wait during file load.

Does this make sense to you @trainman419 ?

[trainman419]

Ok. I'll make that switch the next time I'm touching this part of the code.

[trainman419]

I've played around with this, and found it more useful to set the format text of the existing status bar, instead of using the busy wait mode. It probably still needs more work, for example setting busy wait mode on systems that don't show format text.

I've also found that there's a rendering delay that can cause the UI to become unresponsive after loading is complete.

I'll keep working on this as I have time.

[ablasdel]

The current incarnation seems acceptable and an improvement on the existing system. Feel free to continue working on this but it won't block the merge I plan on monday.

[trainman419]

@jbohren does the solution in #239 satisfy your need for a status bar?

[trainman419]

I'm pretty happy with the current loading UI improvements in #239, and they've been released for a while now. Are these enough to mark this as solved @jbohren ?

[ablasdel]

Due to the recent changes by @trainman419 this has gotten better and I'm going to be bold and close this. @jbohren if you think this is still outstanding please tell me and I will reopen it.