[knipknap]

Problem

The green work-origin (WCS) marker uses the same hairline style as the red axis extent frame. When the work origin sits exactly on the frame corner — e.g. origin top-right at 0,0 — the two overlap and the marker visually disappears (issue #625).

Two stacking problems cause this:

• The Z-order sort in update_from_doc pinned WorkOriginElement at the very bottom of the canvas stack (below the extent frame and nogo zones), so the red frame was always drawn on top of the marker.
• The marker itself was drawn with 90% alpha, further diluting it where the frame overlapped.

Changes

• Arrows instead of lines: the marker axes are now shafts with 45° arrowheads. The arrowheads have a fixed device-space size (6 px) that stays constant across zoom levels, matching the device-space hairline shafts, and are capped to a fraction of the shaft so they cannot outgrow the marker when zoomed far out.
• Fully opaque: the green is now drawn at alpha 1.0.
• Z-order: the marker now sorts above the extent frame and nogo zones, but still below stock, layers, and the laser dot. The initial element order in WorkSurface.__init__ matches.
• Docs: reworded the projector-mode page ("crosshair" → "arrows") in English and all seven translations, and regenerated the main:standard and addon:projector-mode screenshots, which showed the old blended marker.

Testing

• pixi run uitest tests/ui_gtk/canvas2d/: 58 passed (including the 5 test_wcs_visual_marker_location scenarios and the marker visibility render tests)
• pixi run lint: clean
• Rendered the marker over the frame at 1.5×/3×/6× zoom and all four origin corners to verify arrowhead size is zoom-independent and directions are correct
• Screenshot regen diff is confined to the marker corner (692 of 702 changed pixels; the rest is font anti-aliasing noise)

Fixes #625

[github-actions]

🤖 Estimated LLM implementation cost

Replayed each of the 1 commits in this pull request and counted the code lines each commit added or rewrote:

Commit	Message	Lines (add/rewrite)	Est. output tokens	Est. output cost
8d072dbc	fix(canvas): draw the WCS marker as arrows above the extent frame	53 / 26	790	$0.0118
Total		79	790	$0.0118

Added lines by language: Python 41, Markdown 12

Full estimate

Component	Est. tokens	Est. cost
Code emission (79 add/rewrite lines)	790	$0.0118
Context input (reading touched files)	13,033	$0.0391
Conversation replay (≈15× output)	11,850	$0.0355
Prompting (pull request description)	386	$0.0012
Lower bound (output only)	790	$0.0118
Best estimate	26,059	$0.0877

Cost model: ≈10 tokens per code line at $15/Mtok output and $3/Mtok input (assuming heavy prompt caching); input ≈ 15× output for conversation replay; a review round ≈ 42,000 tokens; a failed CI run ≈ 21,000 tokens; file reads capped at 20 kB each.

Active window from first commit to merge: <1 day.

⚠️ Caveat: the lower bound covers only the tokens for emitting the code. The best estimate adds modeled overhead for exploration, conversation replay, review and debug turns, but real sessions vary by tool and task — treat it as an order-of-magnitude figure. Human engineering time is not included.