Canvas로 넘어가는 기준

마지막으로 Canvas로 넘어가는 기준을 정리해봅시다.

지금까지는 CSS와 SVG로 에디터를 만드는 길을 걸었습니다. DOM이 남아 있어서 선택, 접근성, DevTools 디버깅이 편합니다. 하지만 대량 오브젝트, 복잡한 픽셀 효과, 매우 빠른 렌더링이 필요해지면 Canvas나 WebGL을 고민하게 됩니다.

중요한 건 “처음부터 Canvas가 더 멋져 보이니까 갈아타자”가 아닙니다. 무엇이 바뀌고 무엇이 유지되는지 알아야 합니다.

Canvas는 immediate renderer다

CSS/SVG에서는 오브젝트마다 DOM 노드가 남습니다. Canvas에서는 그려진 픽셀만 남습니다.

render loop: clear -> apply camera transform -> draw nodes
hit test는 DOM이 아니라 spatial index + model geometry로 수행한다.

Canvas 전환은 모델을 버리는 일이 아니라 renderer를 바꾸는 일입니다. hit testing과 접근성은 DOM 대신 직접 구현해야 합니다.

매 프레임 지우고 다시 그립니다. 그래서 DOM event target도 없습니다. hit testing은 모델 geometry와 spatial index로 직접 해야 합니다.

Canvas에서는 CSS 크기와 실제 픽셀 버퍼 크기를 분리해야 합니다.

canvas pixel size = cssSize * devicePixelRatio

예를 들어 CSS 크기가 800 x 600이고 devicePixelRatio가 2라면 backing store는 1600 x 1200으로 잡습니다. 그리고 draw 전에 scale을 맞춥니다. 안 그러면 화면이 흐릿해집니다.

Canvas로 넘어가도 지금까지 배운 많은 것은 그대로 남습니다.

바뀌는 것은 주로 렌더링 backend와 event targeting입니다. 그래서 CSS/SVG 단계에서 편집 수학과 상태 모델을 안정화해두면 Canvas로 옮길 때도 덜 흔들립니다.

데모에서는 같은 scene model을 CSS DOM과 Canvas draw call로 각각 표현할 때 무엇이 바뀌고 무엇이 유지되는지 정리합니다.

오늘의 핵심은 Canvas가 CSS의 실패 대체재가 아니라 다른 렌더링 backend라는 점입니다. 모델을 잘 분리해두면 렌더러는 바뀌어도 편집기의 뼈대는 유지됩니다.