SliceViewer raster image performance issues

[Peter Peterson]

The raster image is slow when used with a peaks workspace. It appears that the slowdown is from the raster looking through the list of all peaks that intersect with the current rendering volume. This is much more obvious when the number of peaks passes 5000 (see attached peaks file for MANDI).

[Owen Arnold]

More information needed. I've just tried master on my Mac (debug build) with the peaks file, and it's not noticeably slower with the peaks workspace loaded or not while slicing through the data.

The raster plot does not interact with the Peaks QtWidgets directly. However, when the slice point is moved, all the peaks are updated. Also, when a peaks workspace is added, a widget is created up-front for every single peak. Both of these might present serious bottle necks, but i'd rather see profiler outputs then guess a course of action.

If you happen to have profiler outputs - please attach them. Otherwise I'll use the valgrind plugin to generate them myself.

[Owen Arnold]

This ticket has been fixed by several child tickets. These are summarised below.

#7281 - Profiler work showed that the heaviest consumer of the cpu cycles was QWidget::Update(QRect&), which corresponded to the calls to paintEvent. This was because each peak is represented by its own QWidget. So I refactored to code to have each peak list provide a single QWidget, and use the PhysicalSphericalPeaks and PhysicalCrossPeaks to drive each representation. Gave a massive speed boost, but all processing was still done in the GUI.

#7233 - Created a new algorithm called PeaksInRegion, which processes a peaks workspace in parallel to determine if any peaks are either inside a region of interest, or have a radius large enough that would cause it to intersect the box region. Performance tests indicate that it can process 40'000 peaks in ~0.3seconds on my 8 core desktop.

#7310 - Merged the independent work done in #7233 and #7281 to get the best of both. Used to PeaksInRegion algorithm to process the viewable region, and kept the used the single widget per peaks workspace approach.

There's no code to merge as part of this ticket. But I suggest the tester verifies that the original problem of visualising the MANDI peaks list attached is solved by taking one of the nightly builds and testing it out in the SliceViewer.

[Peter Peterson]

I tested and merged all of the blockers. It is working much better than it did for the demo last month.

[Stuart Campbell]

This ticket has been transferred to github issue ​8063