I have noticed for awhile these weird discontinuities in the markups line object. Specifically when the line is completely horizontal or vertical it can appear that the 2 control points that make up the line are not connected which is unexpected. This appears to be some weird display issue.
Since lines are used in other markups types it can be weirdly rendered in various situations. Not sure if this is some inherent limitation in VTK or what.
All markups lines are represented as tubes (generated by vtkTubeFilter) and it is up to the OpenGL driver to render these polygons. When the size gets comparable or smaller to the screen pixel size then rasterization becomes impossible, so the driver does what it can, which in this case is a kind of dashed/partial line. The exact pattern depends on the angle and position of the line.
It should be possible to detect when the requested thickness becomes so small that it the line cannot be reliable rendered and then hide the line completely (or do not use the requested thickness but the smallest feasible thickness), but I’m not sure it would help users much.
Another approach could be to switch to rendering the line with a 2D actor when the line is too thin. But it could be significant workload to implement and maintain a secondary pipeline and switch between them. Such complexity and workload may not be justified to address an edge case.
Instead of focusing on improving rendering of thin lines, it would be more important to improve appearance of lines in the normal thickness range, using anti-aliasing. As a side product of anti-aliasing, appearance of thin lines could greatly improve, too.
The default line thickness of 20% is just too small to render properly, at least on a 1080p screen. Could we change it to 30%? I’m not seeing any issues at that size.
Line thickness = 20% of glyph size is probably fine, the issue is that the default glyph size is not computed consistently across different screen resolutions - see Markups Display Size · Issue #5180 · Slicer/Slicer · GitHub. I’ll try to find out what causes the glyph size inconsistency and then we should be able to fix the too small default glyph size.