GUI becomes totally unresponsive when streaming a single headstage's worth of npx data

[jonnew]

The workflow consists of the onix source the LFP viewer. LFP viewer shows the scroll line but I cannot click any buttons in the GUI or stop acquisition.

The dev team seems to think that this issue goes away when the the LFP viewer is compiled in release mode. Maybe so, but why? What is the non-optimized part of this code that would cause such catastrophic behavior?

[bparks13]

It appears to be an issue with the GPU. When I switch to the CPU rendering method (View → Renderer → Software (CPU)) there is far less of a performance hit. There is still a slight delay between scrolling and the LFP viewer updating the view, but it is not severe enough to lock the whole UI for minutes at a time. Based on testing, and conversations with the dev team, this does not appear to be an issue with the plugin itself, but rather the hardware (e.g., GPU) we are running the system on.

[bparks13]

Based on testing using the SourceSim plugin in v1.0 of the GUI, this is a combination of a few things:

1. Juce8 changed the default renderer from CPU to GPU, which has a performance benefit for all computers except those with weak integrated GPUs
2. For weak integrated GPUs, the LFP viewer will lock when using the GPU renderer above a certain channel count (this was ~30 channels in one scenario, but this will depend on the specific GPU). The CPU renderer will show a delay between actions, but it does not typically lock up entirely

At the end of the day, this is not a problem with the plugin itself, but if someone connects a headstage with lots of channels (i.e., any of the Neuropixels headstages), and then they want to use the LFP viewer, this will present itself as an issue if their GPU cannot handle the processing load.

I am closing this issue, since we can't fix it from here, but we can reference the issue in case anyone runs into this same problem.