I’m helping someone develop a Guidelet for her research, and I’m running into some very poor performance. We use SlicerIGT to connect to two Plus servers for a combined 2 images and 6 transforms. With some models and resliced views in 3D mode, we’re getting about 9 updates per second and stuttering rendering of the 3D scene.
So, some questions:
The volume reslice driver seems like massive overkill to render a slice with a world transform (or transform chain). My performance analysis puts it at ~8% total CPU samples. Is there a less expensive way to render a slice in the 3D view with a non-identity IJKtoRAS?
Are their any performance optimization options for OpenIGTLink handling receiving of data. It’s a bit hard to tell as I’m new to performance reports, but it looks like there’s a lot of redundant observed event triggers.
This is more like a troubleshooting question than a real answer but do you use two layout managers or one?
If the guidelet opens in a new window instead of using Slicer’s main window then there are performance issues. That’s why the guidelet people here implemented their programs to alter Slicer’s main window instead of opening a new one (if what I heard a while back is still valid).
Hi @adamrankin - If you have an easy way to replicate the issue (like a self test with dummy data) we could try various profiling and optimization options.
Well, sadly not easy, as it requires the connections to Plus servers to see the performance dip. I could record some sample data to replay, but it would still require running the two servers and the Guidelet.
Instead of using the volume reslice driver, I think I can continuously update the IJKtoRAS of the slice and let the Slicer infrastructure take care of rendering it in the right place.
Edit: nevermind, it doesn’t work. Only a sliver is visible.
Do you see better performance with setting SliceToRAS matrix and the slice image? That’s interesting, because volume reslice driver does exactly that.
Extra modified events should not cause too much performance decrease, because data processing is performed only when the rendering pipeline requests the data, and rendering is not triggered directly modified events. Modified events usually just call scheduleRender, which eventually triggers an actual rendering update.
I am seeing a lot of function calls relating to reslicing that are not just setting a matrix. A lot of data copying and interpolation. Reslicing accounts for almost 10% of samples in my performance analysis, and it should be simply copying memory to the GPU and updating the world transform.
I’m seeing if I can export my performance analysis for others to look at, as I am new at this and am probably reading it wrong.
I’m not sure yet regarding modified, but when I connect/disconnect the OpenIGTLink connector nodes via GUI, I can see an immediate performance drop/recovery for each connector connected.
When I connect the plus server with the US image and tracker, the update per second of a transform from the first connector goes from ~42u/s to ~9u/s.
What is the cheapest way to render a slice in the slice view (with no reslicing, just as is, ignoring all transforms, scaling to fit window) and the same slice in the 3D view with the world transform applied?
Linear transforms don’t really add any extra processing expense to slice view reslicing. It sounds like the issue is more likely to be in the event processing so the performance analysis is critical. You could try some experiments like selectively disabling certain features (like the 2D or 3D displays) to isolate where the time is being spent.
How much refresh rate improvement do you think you would get by reducing resampling time to 0sec?
In general, resampling is needed because foreground, background, and labelmap volumes have to be resampled to a common grid so that they can be composited. This could be changed by creating a smarter 3D displayable manager for slices, which would not do any resampling if only layer is visible. When there are multiple visible layers, this smarter displayable manager may implement compositing in the render window instead of computing the composited image in CPU.
A few, but in conjunction with identifying the OpenIGTLinkIF slow performance, up to “real-time” refresh rate. Right now if I can get it up to ~15fps, that would be great.
