You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been testing the 1.0 preview, and we have noticed that with our integrated GPU the LFP Viewer tends to delay UI elements, or lock them out entirely. This usually occurs while scrolling or trying to drag the scroll bar.
This has been tested with Neuropixels 1.0 probe data, so there are 384 channels to deal with, but this points to some possible inefficiencies in the processing pipeline for the LFP viewer. It seems that this problem is not seen in more powerful machines, but if the plugin can be optimized for low power graphics processors then it should benefit all levels.
I would be happy to provide some benchmarks, and some profiling, on the machine in question to provide a baseline for testing purposes.
The text was updated successfully, but these errors were encountered:
In GUI v1.0, we've updated the JUCE framework to version 8. With this update, the Direct2D renderer is now the default renderer on Windows.
Direct2D offers substantial rendering and performance improvements for applications built with JUCE 8. Both desktop windows and images are now GPU-backed on Windows. Previous versions of JUCE used the Software renderer, which relies on the CPU and RAM for rasterization and storage of images.
According to the JUCE 8 Direct2D blog here, performance should improve on most machines with the new Direct2D renderer. However, older machines with integrated GPUs (and no dedicated VRAM) might not perform as well on Direct2D as they did with the software renderer, due to the lack of dedicated memory and shared RAM with the CPU.
Considering this, and following the JUCE guidelines, we've added the option to toggle the renderer used by the GUI. You can toggle this setting via View → Renderer. By default, the renderer is set to Direct2D, but if you encounter lag or UI lockups—particularly on machines with integrated GPUs—we recommend switching to the Software (CPU) renderer. This is similar to other GUI-based applications (e.g., web browsers and chat apps) that allow users to disable hardware acceleration.
The UI lockups you’re experiencing in the LFP Viewer are likely due to Direct2D running on an older integrated GPU. Switching to the Software renderer should resolve this issue, especially when working with high-channel count data.
These changes only affect Windows. Rendering on macOS (Core Graphics) and Linux (Software rendering) remains unchanged.
We have been testing the 1.0 preview, and we have noticed that with our integrated GPU the LFP Viewer tends to delay UI elements, or lock them out entirely. This usually occurs while scrolling or trying to drag the scroll bar.
This has been tested with Neuropixels 1.0 probe data, so there are 384 channels to deal with, but this points to some possible inefficiencies in the processing pipeline for the LFP viewer. It seems that this problem is not seen in more powerful machines, but if the plugin can be optimized for low power graphics processors then it should benefit all levels.
I would be happy to provide some benchmarks, and some profiling, on the machine in question to provide a baseline for testing purposes.
The text was updated successfully, but these errors were encountered: