Small screen-space "dash" appears at curve midpoint after cloning a Markups curve (Markups → Clone)

Support
1

Environment: 3D Slicer 5.12.3, Windows 11

Summary

After cloning a Markups curve via the Markups module (right-click a curve node in the list → Clone), the cloned curve displays a small horizontal line (“dash”) at (or very near) the curve’s midpoint. The original curve does not show it. It reproduces reliably, including with a freshly drawn dummy curve (4 arbitrary points).

The midpoint location is confirmed by the control point counts: most of my curves have 4 points, and their dash sits next to the second control point; one curve has 5 points, and its dash sits next to the third control point (its exact middle). So the dash tracks the curve’s midpoint, not a specific control point.

Screenshot 2026-09-30 170005
Screenshot 2026-09-30 170005339×280 39.1 KB

Screenshot 2026-09-30 131415
Screenshot 2026-09-30 131415242×249 15.5 KB

Observed behavior

  • The dash is always screen-horizontal and projects to the right of the curve regardless of camera angle — suggesting a 2D/screen-space actor rather than 3D scene geometry. It is also always the same pixel size no matter how much I have zoomed in or out on the 3D scene.

  • It follows the curve’s midpoint wherever the geometry goes: moving any control point — including programmatically via SetNthControlPointPosition() — moves the dash along with the curve. Initially it looked tied to control point 2, because on my 4-point curves the midpoint happens to sit right next to that point; the 5-point curve (dash at its middle point) confirms it tracks the midpoint.

  • It appears immediately upon cloning, before any geometry or display changes.

  • It highlights (active color) together with the curve when hovering the curve, but is not individually clickable/selectable.

  • Toggling the clone’s display node visibility hides the dash together with the curve; restoring visibility brings it back.

What I ruled out (all compared between original and clone, all identical):

  • Display node properties: point label visibility (off), text scale (0), glyph type (Sphere3D), glyph scale, line thickness, curve line size mode, fill/outline/occluded visibility, rotation/translation/scale handle visibility, interaction handle scale.

  • No measurements exist on either node (“no measurements” in the Markups Measurements section).

  • Per-point properties: labels, position status (all defined), locked and selected flags — identical on all 4 points of both nodes.

  • Node class is identical (vtkMRMLMarkupsCurveNode) and the two nodes have separate display nodes (not shared).

  • Changing the curve type (spline → polynomial / Kochanek) does not remove the dash.

  • Changing point spacing/geometry (including widening the gap between points 1 and 2) does not remove the dash.

Renderer inspection

Iterating the 3D view renderer’s visible props near the curve shows two vtkSlicerCurveRepresentation3D instances with nearly identical bounds:

3D: vtkSlicerCurveRepresentation3D | bounds: [6.6, 15.3, -79.2, -67.8, -221.2, -211.8]
3D: vtkSlicerCurveRepresentation3D | bounds: [5.8, 14.3, -86.6, -73.5, -242.8, -233.0]

(The bounds above reflect the curve after control point positions were moved during testing.)

My chatbot’s suspicion

The Markups “clone” operation appears to leave behind (or create an extra) curve widget/representation in the view, which renders a small screen-space element anchored to the curve’s midpoint — the same location where the markups interaction-handle widget places its center elements. Because this element is drawn by a stale/duplicated representation rather than the live display node, changing display properties (handle visibility, glyph type, labels, measurements) has no effect on it. It could be a degenerate center/handle/label actor that the duplicated representation never cleans up.

Questions

  1. Is this a known issue with the Markups “clone” operation?

  2. Is there a workaround to remove the stray element without deleting and recreating the cloned nodes?

  3. Is there additional diagnostic information I could collect that would help pin this down (e.g., a way to identify which of the two vtkSlicerCurveRepresentation3D instances draws the dash)?

I’ve checked the 5.12 release changelog including the 5.12.4 patch notes and found no mention of a related fix. The new arrow glyph types (Arrow2D etc.) are not in use here — both nodes’ glyph type is Sphere3D.

Thank you!