qcast-front/.claude/memory/feedback_same_point_tolerance.md

2.0 KiB

name description type
좌표 매칭 tolerance 는 UI drift 고려해 넉넉히 평행 이동 등 baseLines / selectLine 좌표 매칭용 isSamePoint 는 기본 0.1 이 아니라 0.5 사용. UI 클릭 시점과 저장값 차이 + Big.js 누적 연산 drift 를 포용해야 "동일 선으로 보이는데 매칭 0개" 로 dy 미적용되는 undershoot 회피. feedback

매칭용 isSamePoint 호출에는 tolerance=0.5 를 명시적으로 넘긴다 (기본 0.1 은 너무 빡빡, 1.0 은 과하게 관대).

Why:

  • 사용자 입력은 소수 2자리(0.01)까지, 마우스 hover 로 "정확히 잡았다"고 보여도 클릭 순간 좌표가 미세하게 달라짐 (UI 라운딩/이벤트 시점 차이)
  • selectLine 좌표(UI)와 wall.baseLines(Big.js 누적 연산: /10, offset 덧셈, 재생성)가 서로 다른 경로로 오기 때문에 실측 drift 상한 0.30.4
  • 기본 0.1 tolerance 로는 matchingLines 가 간헐적으로 0개 → dy 미적용 → 같은 입력인데도 "어떤 때는 못 미치고 어떤 때는 정상" 불안정 체감이 발생했음
  • 1.0 은 실측 10mm 가까이라 과하게 관대 — 사용자가 "같은 선이 아닌데 잡혔다" 느낄 여지
  • 0.5 는 드리프트 상한(~0.4) 여유 포용 + 이웃 edge 오매칭 위험 사실상 0 의 균형점
  • 전역 isSamePoint 기본값은 건드리지 않고 매칭 필터 site 에만 명시 전달 (다른 호출처 영향 차단)

How to apply:

  • skeleton-utils.jsmovingLineFromSkeleton matchingLines 필터, buildRawMovedPoints matchingLines 필터 등 "UI 좌표 vs 내부 계산 좌표" 비교 site 에는 전부 0.5 지정
  • 내부 계산 좌표끼리 비교(예: polygon 내 인접 edge 연결 판정)는 기본 0.1 유지 — drift 원인이 UI 아니면 필요 없음
  • 새로운 매칭 filter 를 추가할 때도 UI 경유 좌표가 끼면 tolerance=0.5 기본 고려
  • 변경 이력: 1차로 1.0 도입 → "과하게 관대" 피드백으로 0.5 로 축소 (2026-04-23)