에디터 입력 지연: 타이핑 시 글자 반영이 너무 느려 편집이 어려움

[lens0021]

증상

apps/editor-poc에서 본문을 편집할 때, 입력한 글자가 화면에 반영되는 속도가 너무 느려서 실사용이 어렵습니다. 타이핑이 화면을 따라오지 못합니다.

관련 증상(동일 근원으로 추정): 링크가 포함된 다소 긴 HTML을 붙여넣으면 페이지가 잠시 멈춥니다(#관련).

환경

• apps/editor-poc — typie의 Svelte 뷰 레이어(View/Page/Input + editor.svelte.ts)를 그대로 재사용하는 구성.
• vite dev(개발 서버)로 실행 중. 프로덕션 빌드에서의 측정은 아직 안 함.

추정 원인 (가설, 미확정)

typie 에디터의 브라우저 렌더러는 CPU 기반입니다 — upstream/typie/crates/editor-ffi/src/platform/wasm_browser.rs의 RenderBackend::new_cpu가 페이지를 CPU로 래스터화한 뒤 캔버스 2D 컨텍스트에 putImageData로 그립니다(WebGL/WebGPU 아님). 그리고 WASM이 워커가 아닌 메인 스레드에서 동기로 돕니다.

따라서 키 입력마다 입력 → WASM 처리 → 레이아웃 → 전체(또는 큰 영역) CPU 래스터 → putImageData가 메인 스레드에서 동기로 일어나며, 이게 입력 지연의 원인으로 보입니다. dev 빌드(비최적화 + HMR 오버헤드)가 이를 더 악화시킬 수 있습니다. 붙여넣기 멈춤도 같은 경로(HTML 파싱+노드 삽입+재렌더가 동기)입니다.

확인/개선 방향

1. 프로덕션 빌드 측정: vite build + preview에서도 동일하게 느린지 확인해 dev 오버헤드를 분리.
2. 렌더 비용 프로파일: 키당 재래스터/재present 범위를 측정. damage-only 렌더, RAF 프레임 합치기(coalescing), 보이는 페이지만 렌더 등으로 축소 가능한지.
3. 메인 스레드 블로킹 해소: WASM 렌더를 Web Worker + OffscreenCanvas로 옮길 수 있는지(typie 본가 구조 변경 필요할 수 있음).
4. 본가 대조: typie 공식 서비스에서도 같은 지연이 있는지 확인 — 본질적 특성인지 우리 구성(빌드/뷰포트/스케일) 문제인지 구분.
5. 렌더 입력값 점검: scale_factor(devicePixelRatio), 캔버스 백킹 크기, 페이지 수가 래스터 비용에 미치는 영향.

참고

• 직접 마운트가 아니라 typie 뷰 레이어 재사용 구성입니다(관련 설계: docs/ARCHITECTURE.md).
• "fork 안 함" 원칙상 typie WASM 자체 수정은 마지막 수단.

🤖 Generated with Claude Code

[lens0021]

성능 조사 결과 + 1차 개선 적용

headless 하네스(puppeteer, 실제 키 입력 버스트로 long task·input→paint 지연 측정)로 지표를 잡고 원인/레버를 정량화했습니다.

원인 (정량 확인)

입력 지연은 문서 크기 × devicePixelRatio² 로 증가합니다. typie의 CPU 렌더러가 키 입력마다 보이는 캔버스를 통째로 재래스터 + putImageData(변경량 무관, dirty-rect 없음)하기 때문입니다.

문서(dpr)	키당 지연 med/p95	long task	fps
2000자 (dpr1)	24/37ms	0	59
2000자 (dpr2)	35/45ms	56ms×1	37
5000자 (dpr2)	88/111ms	3470ms×40	17
5000자 (dpr3)	143/192ms	5740ms×40	10

검증한 레버

• 프로덕션 빌드: 효과 없음(dpr2·5000자 dev 88ms ≈ prod 87ms). → 병목은 JS/dev 오버헤드가 아니라 WASM 네이티브 CPU 래스터.
• 페이지네이션 레이아웃: 효과 없음(보이는 영역을 어차피 통째 래스터, 오히려 소폭 악화).
• 렌더 스케일 캡(devicePixelRatio 캡): 유효. 유일한 no-fork 레버.

적용 (커밋 7d74767)

main.ts에 RENDER_SCALE_CAP(기본 1.5) 추가 — hidpi에서 렌더 스케일을 낮춰 선명도를 조금 내주고 응답성을 얻음. before→after(dpr2):

문서	지표	before	after(1.5)
2000자	long task / fps	56ms×1 / 37	0 / 45
5000자	지연 med / fps	84ms / 17	64ms / 23

일반 크기 문서는 long task 0으로 매끄러워졌고, 초대형 문서는 ~24% 개선(부분적).

남은 근본 해결(별도, fork 필요)

완전 해결은 변경분만 다시 그리는 dirty-rect 렌더링입니다. crates/editor-ffi/.../wasm_browser.rs present()가 전체 버퍼+putImageData 전면, cpu/sink.rs flush_to()가 항상 풀프레임이라 damage 추적 API가 없습니다. → typie 렌더러(crate) 수정 필요. 그 외 Worker+OffscreenCanvas로 메인 스레드 분리도 후보(구조 변경).

🤖 Generated with Claude Code