[Feature Request] Reduce Brushing Lag with LABELMAP_EDGE_PROJECTION_BLEND

[stada526]

What feature or change would you like to see made?

Using LABELMAP_EDGE_PROJECTION_BLEND makes the brushing function sluggish.
I’ve prepared an example to reproduce this issue. In the example, two additional MIP viewports have been added, and you can observe that brushing becomes very sluggish.
I also confirmed that even having just one or two MIP viewports with LABELMAP_EDGE_PROJECTION_BLEND makes the brushing noticeably sluggish.

I’d really appreciate it if this feature could be optimized to make the brushing smoother.

Why should we prioritize this feature?

Because it’s common to have two MIP viewports for sagittal and coronal orientations.

[sedghi]

Maybe we should do a debounce or something for it
But basically the logic happens here

packages/tools/src/tools/displayTools/Labelmap/addVolumesAsIndependentComponents.ts

onSegmentationDataModified

Maybe try a debounced version and i can merge

[stada526]

Thank you for the information! If no one has enough time to work on it, I'll take a look when I get the chance.

[stada526]

Hi @sedghi ,

I tried making some changes to improve the performance by referring to your suggestion.
https://github.com/stada526/cornerstone3D/pull/3/files#diff-8823dec9c5d863a003e28742c91dd09c43727d7cb2aca0c5b1d1b4d0f966b97e

Do you think I’m on the right path?

Additionally, I’m encountering an issue where the segmentation rendering is delayed.
Do you know of any possible causes?

2025-02-19.13.28.19.mov

[sedghi]

I don't think this is the right path, maybe look at how we can calculate index without doing the getAtIndex

[stada526]

Thank you for your quick reply!

I'd like to know more details about what you meant.

I believe the bottleneck is the following part of the onSegmentationDataModified function.
The order of dims[0], dims[1] and slices depends on the data and how the brush is stroked, but they're basically around 10^2 each, which means this loop runs 10^6 iterations. Additionally, this callback function is called very frequently as you mentioned, which I believe is causing the performance issue.

    for (const z of slices) {
      for (let y = 0; y < dims[1]; ++y) {
        for (let x = 0; x < dims[0]; ++x) {
          const iTuple = x + dims[0] * (y + dims[1] * z);
          baseData[iTuple * newComp + 1] = segVoxelManager.getAtIndex(
            iTuple
          ) as number;
        }
      }
    }

I still don't understand how looking into ways to calculate the index without using getAtIndex could solve this issue.