Experiment with 1:1 ConcretePeaksPresenter to QWidget

[Owen Arnold]

Currently the PeaksViewer is proving to be slow when used with many peaks ~7000 (see 7217). My profiler checking indicates that QWidget::Update(QRect&) is the main offender, as it is called for every peaks widget (each peak being represented by a widget).

As a first step towards #7217 i'd like to quickly verify that the problem can be addressed by changing the way that the QWidgets are used to paint the overlay. Instead of having n widgets for n peaks, we could have one widget for each concrete peaks presenter, and use the PhysicalSphericalPeaks and PhysicalCrossPeaks respectfully to drive the widget creation for the subset of viewable peaks.

Should this work, then we should finally address #7217 by bringing in the new algorithm PeaksInRegion to make the peaks processing even faster.

[Owen Arnold]

From the hacking I've done so far, this is really encouraging! I ran the following to create a dummy MDWorkspace, and then overlayed MANDI_306_predicted.peaks ( 11415 peaks. ). Visualisation of peaks is instantaneous while moving through the slices.

CreateMDWorkspace(Dimensions='3',Extents='-10,10,-10,10,-10,10',Names='Q_lab_x,Q_lab_y,Q_lab_z',Units='A,A,A',OutputWorkspace='WS')
BinMD(InputWorkspace='WS',AlignedDim0='Q_lab_x,-10,10,100',AlignedDim1='Q_lab_y,-10,10,100',AlignedDim2='Q_lab_z,-10,10,100',OutputWorkspace='v')

[Owen Arnold]

refs #7281. Single widget version for comparison.

This has been somewhat rammed in.

However, its not worth a clean implementation here unless we know that the effort will be worth it.

Changeset: 64ef263829ab73a98a0ad1d4c3bf5c6f38b07089

[Owen Arnold]

refs #7281. Make room for PeakOverlayMultiSphere.

Changeset: 496d05509f9c4b2ddd7dd12ce8863ce2ff0139b0

[Owen Arnold]

refs #7281. Add in spherical multi peak factory.

Changeset: df207c093e327565c9ae90d802327e7c699b41fa

[Owen Arnold]

refs #7281. Remove old widget and widget factory types.

Changeset: 04c2fb5b399e9d41bc38c8eb40156d9692975830

[Owen Arnold]

refs #7281. Refactor factory and view interfaces.

.White box testing provided by the mocking framework has been a lifesaver here!

Changeset: 0874d4dc2b777f05b17d509e459309ba928d40f3

[Owen Arnold]

Tester: Thorough testing is really important for these changes.

1) Follow the earlier instructions involving the MANDI peaks file. Then, using the sliders or clicking on a peak to zoom in on it should be very rapid now.

2) Look at the feature descriptions here http://www.mantidproject.org/PeaksViewer. You must verify that all of these features are still working.

[Owen Arnold]

refs #7281. Regression tests added.

.Menu options were broken as forgot to reimplement.

Changeset: 5de1883f3b97ecc8f27f418a3cba0adcb8937f78

[Peter Peterson]

I really wanted to pass this one when I saw how responsive the raster image is. There is a bug in it. The view does not appear to hide peaks that are not in the current range. To reproduce:

• Use MantidEV to create MD workspace and peaks workspace (findpeaks).
• Plot the data with the peaks overlay
• Sort the peaks by "DetID"
• Look for an area where there are peaks markers by clicking on various peaks, but the data values appear to be background.
• I found a pair on pixels 1469766 and 1479234 which have markers when you click on either, even though the slice seems too thin for the other to show up

This may be a misunderstanding that arises from the thickness of the slice not being obvious. The problem is that it looks like there are extra markers where there isn't higher intensity which doesn't make sense when overlaying "found peaks."

[Peter Peterson]

Actually the bug mentioned in the bounce message is there in master as well.

There is a real issue that the "Coordinates:" label in the peaks table displays Q-lab when the data is annotated as Q-sample. The numbers match up with it being in Q-sample too.

[Peter Peterson]

The bug in #comment:12 is now #7297.

[Owen Arnold]

I think you've come up against a feature of the peak position markers. To explain this, I'll start by talking about integrated spherical peaks... taking account of peak center positions only, when you move the slider, if you don't happen to move the slider exactly to center position of the peak, you won't see it. This would make the peaks overlays in the sliceviewer unusable, so I handle this for the spherical peaks by modifying the opacity and circle projection size as the slicing plane moves away from the peak center (see ASCII art, line 52 in PhysicalSphericalPeaks.cpp). For integrated peaks, this can be done accurately, because the peak integration routines specify a fixed radius size, so if the plane - center distance is greater than the integration radius, nothing is drawn. For the unintegrated peaks (represented by a cross), there is no integration radius to use, but you would still want each marker to have a finite sized location so that you wouldn't miss it as you track the slice slider along. So an effective peak radius is artificially constructed to be some small fraction of the total z-range. You can actually modify this using the controls here: http://www.mantidproject.org/PeaksViewer#Preference_Options.

Try the following:

1) Zoom in on a peak by clicking on it in the table

2) Open up the peak preference options and reduce the Peaks size into projection slider to the minimum. As you do this, you should see the other peaks (those not zoomed in on) disappear from the view.

[Owen Arnold]

The issues that Pete observed have been fixed under #7303 as they were already present in Master.

[Stuart Campbell]

This ticket has been transferred to github issue ​8127