napari: Significant performance degradation of the brush rendering
🐛 Bug Report
I’ve tested the latest main branch and found out that since my last optimization (#5732) there has been a noticeable degradation of the rendering performance.
When I run examples/add_labels.py
, I cannot see anything above 35-40 FPS and the brush feels laggy. Moreover, all 16 cores of my CPU are heavily loaded when I use the brush, as it can be seen in the video below:
https://github.com/napari/napari/assets/5459767/2e39c010-2770-4f73-8778-9c68392175bd
In comparison, when I switch to #5732, it shows stable 60 FPS and almost all the CPU cores are free:
https://github.com/napari/napari/assets/5459767/0485ed09-9779-4b71-bb39-a0b10e69c0d8
I think that it is also related to the big changes in the color mapping and rendering code that were introduced in https://github.com/napari/napari/pull/6439, https://github.com/napari/napari/pull/3308
💡 Steps to Reproduce
- I added the following code to measure FPS to
examples/add_labels.py
:
def update_fps(fps):
"""Update fps."""
viewer.text_overlay.text = f"{fps:1.1f} FPS"
viewer.text_overlay.visible = True
viewer.window._qt_viewer.canvas._scene_canvas.measure_fps(callback=update_fps)
💡 Expected Behavior
No response
🌎 Environment
napari: 0.1.dev3200+gbb785f3.d20240108 Platform: Linux-5.15.0-91-generic-x86_64-with-glibc2.29 System: Ubuntu 20.04.6 LTS Python: 3.8.10 (default, Nov 22 2023, 10:22:35) [GCC 9.4.0] Qt: 5.15.2 PyQt5: 5.15.10 NumPy: 1.23.0 SciPy: 1.10.0 Dask: 2023.3.2 VisPy: 0.14.1 magicgui: 0.7.2 superqt: 0.6.1 in-n-out: 0.1.7 app-model: 0.2.4 npe2: 0.7.3
OpenGL:
- GL version: 4.6.0 NVIDIA 525.147.05
- MAX_TEXTURE_SIZE: 32768
Screens:
- screen 1: resolution 2560x1440, scale 1.0
- screen 2: resolution 1920x1080, scale 1.0
Settings path:
- /home/konstantin/.config/napari/usr_5c0e77c46be77719bc1c0a5ec9c64b94d2a2e50c/settings.yaml Plugins:
- napari: 0.1.dev3200+gbb785f3.d20240108 (81 contributions)
- napari-console: 0.0.9 (0 contributions)
- napari-svg: 0.1.10 (2 contributions)
💡 Additional Context
No response
About this issue
- Original URL
- State: closed
- Created 6 months ago
- Comments: 27 (13 by maintainers)
Commits related to this issue
- Fix labels mapping cache by filling it with background, not 0 (#6580) # References and relevant issues closes #6578 updates example to mitigate #6579 # Description As unknown values are m... — committed to napari/napari by Czaki 6 months ago
- Fix labels mapping cache by filling it with background, not 0 (#6580) # References and relevant issues closes #6578 updates example to mitigate #6579 # Description As unknown values are m... — committed to napari/napari by Czaki 6 months ago
- No-cache fast painting (#6607) # References and relevant issues closes #6579 supersedes #6583 # Description #5732 introduced a cache of mapped data so that only changed indices were mapped... — committed to napari/napari by Czaki 5 months ago
- No-cache fast painting (#6607) closes #6579 supersedes #6583 were mapped to texture dtypes/values and sent on to the GPU. In this PR, an alternate strategy is introduced: rather than caching previou... — committed to napari/napari by Czaki 5 months ago
The CPU monitor is not showing a proper workload. It shows 100% on all cores, but it does not consume the whole CPU time. It is a sequence of spikes. And CPU monitor shows top usage along measure period that is much longer than the spike during paint.
I even worry that here spawning threads generate problems and maybe for small arrays we should use a sequential version.
I think that it may be worth waiting on sckit-image release, but I may check the sequential version for small arrays. Especially in painting, we change every updated pixel to the same value.