Poor napari performance when `data.show()` renders `RegionsData` with many keys**

[jwrth]

Description

Calling data.show() on an InSituData object with a RegionsData containing many keys is very slow. Each key in RegionsData is rendered as a separate napari Shapes layer via _add_geometries_as_layer() (one viewer.add_shapes() call per key). With ~20+ region keys, the viewer can take 30+ seconds to open.

Root cause

In insitupy/interactive/_layers.py, _add_geometries_as_layer() calls viewer.add_shapes() once per RegionsData key. This triggers a known napari performance bottleneck (napari/napari#1562) for every layer:

• CPU-side polygon triangulation and mesh generation (vispy) per layer
• Z-order reindexing of the Shapes mesh on every shape addition (O(n²) during init)
• Repeated thumbnail generation during Shapes.__init__
• A full Qt canvas redraw triggered per layer insertion (Viewer gets slow when having multiple Points layers napari/napari#6658)

Minimal example

import insitupy as ispy
data = ispy.InSituData.read("path/to/project/")
# data.regions has 30 keys -> 30 separate viewer.add_shapes() calls
data.show()  # very slow

Proposed solutions

1. Consolidate region keys into fewer Shapes layers - The most impactful fix. Rather than one layer per RegionsData key, group all region polygons into a single Shapes layer and use the properties dict (e.g. properties={"key": [...], "class_name": [...]}) to encode per-polygon metadata. This reduces viewer.add_shapes() from O(n_keys) to O(1). The existing sync_geometries() logic would need updating to parse layer properties back into the key/class structure.

2. Block canvas redraws during batch insertion - As a lighter fix, wrap the loop over region keys in an event blocker:

   with viewer.layers.events.inserted.blocker():
       for key in data.regions.keys():
           _add_geometries_as_layer(...)

   This avoids redundant Qt redraws between layer insertions.

3. Defer thumbnail generation - Shapes layer performance napari/napari#1562 identified repeated thumbnail updates during Shapes.__init__ as a major overhead. Until this is fixed upstream, it could be partially mitigated by deferring viewer.add_shapes() calls (e.g. lazy layer creation on first pan/zoom into a region).

References

• [napari/napari#1562 - Shapes layer performance (profiling, z-order reindexing bottleneck)](Shapes layer performance napari/napari#1562)
• [napari/napari#6658 - Viewer gets slow with multiple Points/Shapes layers](Viewer gets slow when having multiple Points layers napari/napari#6658)