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

  1. 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

Most upvoted comments

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.