WTrackMenu: Cleanup & performance regression fixes (part 2)

[uklotzde]

@Be-ing @hacksdump

As promised another round of optimizations for #2612. This one fixes some more regressions and also an indexing bug in a loop in updateMenu() that only considered the first element.

We need to optimize updateMenu() that still is very inefficient and able to freeze the UI longer than acceptable. This was already an open issue before extracting the WTrackMenu class.

The major regression and pain point caused by getTrackPointers() is still unresolved, I added comments. A proof-of-concept for handling those long running actions is ready for testing. Next time ;)

[Be-ing]

I don't know how to do this in C++, but I am wondering if we could create some sort of asynchronous iterator class that only keeps a single TrackPointer in memory at a time.

[uklotzde]

I don't know how to do this in C++, but I am wondering if we could create some sort of asynchronous iterator class that only keeps a single TrackPointer in memory at a time.

I have prepared a small, internal framework for exactly this purpose, part of #2656 (which also includes the pending changes for WTrackMenu). It is not asynchronous, single tracks are still loaded in the UI thread, and all the work is done in the main thread. This is acceptable as long as we provide progress feedback and an option to abort long running operations. It saves us from managing and controlling multiple background tasks and is already a huge improvement compared to the current situation.

[uklotzde]

Force pushed, because the last commit did not build.

[uklotzde]

I have compared the code in WTrackMenu with that in WTrackTableView. Unfortunately WTrackMenu::updateMenus() is causing a major performance regression by loading all tracks at once instead of obtaining this information from the TrackModel as before. This still needs to be fixed. Fixed

[uklotzde]

WTrackMenu::updateMenus() should finally be fixed. This was the most urgent issue.

[Be-ing]

Beyond the scope of this PR, but related: I think mass actions get slowed down a lot by writing to file tags. This is unnecessary when I clear analysis settings right before reanalyzing. Maybe we can come up with a way to improve this.

[Be-ing]

The code looks good to me. I will test it after my ongoing reanalysis finishes.

[uklotzde]

Beyond the scope of this PR, but related: I think mass actions get slowed down a lot by writing to file tags. This is unnecessary when I clear analysis settings right before reanalyzing. Maybe we can come up with a way to improve this.

We don't have the facilities for managing queued background tasks. The only exception is the special case multi-threaded batch analysis.

The first step towards a better user experience is to show a modal progress report and the option to abort long running tasks as demonstrated in #2656. Any non-modal extensions are out of scope yet.

[Be-ing]

Beyond the scope of this PR, but related: I think mass actions get slowed down a lot by writing to file tags. This is unnecessary when I clear analysis settings right before reanalyzing. Maybe we can come up with a way to improve this.

This could be done with a reanalyze action. That would also require adding a progress bar to the GUI. Then we could finally get rid of the unintuitive Analyze LibraryFeature.