fix: 레이아웃 LRU가 그 패스 자신의 작업 집합을 자르던 것 (#59 감사)

[centwon]

요약

PR #59(메모리 쥐어짜기) 감사. 09-24 감사 이후 들어온 자기 변경분만 골라, 해제·재사용 조합을 추적하고 테스트로 확인했다.

결함 (성능) — 레이아웃 LRU가 그 패스 자신의 작업 집합을 잘랐다

• TrimLayoutCache가 사용 순서로만 256개를 남겨, 한 패스가 384개(256 + 여유 128)를 넘게 쓰면 먼저 그린 레이아웃이 패스 끝엔 가장 오래된 것이 되어 버려졌다.
• 캐럿 깜빡임은 캔버스 전체를 다시 그린다 → 변경 없이 0.5초마다 346개 생성·해제(30×20 표, 새 LayoutBuilds 훅으로 계측).
• 상류 WIP의 같은 LRU(renderStart)처럼, 패스 시작 이후 쓴 항목은 건드리지 않게 했다(TrimLayoutCache(passStart)).

문제없음 확인 (추적)

• 레이아웃을 await 너머로 쥐는 경로 없음(호출부 전부 동기, 인라인 표 walk는 핀)
• 캔버스 무효화는 전부 전체 무효화 → 보이는 그림의 위치 기록이 늘 새로 찍힘
• 인쇄·벡터 PDF: 해제된 그림은 "안 그린 그림"과 같은 상태(기존 인쇄 테스트가 덮음), D2D가 비트맵 참조를 따로 잡음
• CanvasDevice.Trim은 Win2D가 D2D 리소스 잠금을 잡고 호출(멀티스레드 팩토리)

테스트

• 새 2건: 변경 없는 패스는 레이아웃을 만들지 않는다 / 트리에서 빼기 → API 편집 → 다시 넣기 2회
• 반증: 보호를 끄면 Expected 0, Actual 346 · 표식/문단 레이아웃을 Dispose만 하고 남기면 다시 그릴 때 실패
• 전체 953/953 통과

남은 것

• 1.3.0 게시 전 AOT 동등성 스윕 재실행(사람이 있는 데스크톱에서)

🤖 Generated with Claude Code