크롬, HTML을 캔버스에 그리는 HTML-in-Canvas API 오리진 트라이얼 시작
- HTML-in-Canvas API의 오리진 트라이얼이 시작되어 개발자가 실제 사이트에서 이 기능을 시험해볼 수 있음
- DOM 요소를 캔버스에 그리는 방법을 캔버스 기본 설정, 렌더링, CSS transform 갱신 세 단계로 설명함
- Three.js와 PlayCanvas의 라이브러리 및 프레임워크 지원 내용을 별도 항목으로 다룸
- 댓글에 따르면 픽셀을 읽어 방문 링크 색이 새는 문제는 read-back-allowed rendering 개념으로 해결하려는 제안임
Hacker News opinions
예전 WebVR 때는 보안 때문에 절대 안 된다고 했는데 지금은 왜 180도 바뀐 건지 궁금함. 구글 내부 팀에서 이걸 의존성으로 쓰게 돼서 그런 거 아닌가 싶음
방문 링크를 캔버스에 그린 뒤 픽셀 색을 읽으면 visited 상태가 새는 문제가 원래 걸림돌이었음. 댓글 보니 read-back-allowed rendering 개념으로 막았다고 하더라
보안은 이진법이 아니고 얼마나 돈 들여서 안전하게 만들 거냐의 문제임. 비즈니스 케이스가 있는 기능에 자원이 더 붙는 건 당연하지
체크박스에 getContext 붙이는 식은 별로 안 와닿음. 캔버스 안 3D 오브젝트 모양에 맞춰서 HTML이 적응해야 하는 경우라면 그건 CSS paint API 쪽 얘기에 더 가까움
웹 게임 하는 입장에서는 이 기능의 킬러 포인트가 입력창이랑 텍스트 렌더링임. 그건 캔버스만으로는 진짜 힘든 부분이라서 이게 필요함
나는 캔버스 워크스페이스를 만들고 있는데 HTML로 패널 50개 넘어가니까 반응이 확 떨어져서 캔버스로 갈아탔음. 지금은 1000개 넘는 패널을 60fps로 돌리지만 마크다운 라이브러리 하나 못 붙이는 게 너무 불편함. html-in-canvas 다시 봐야 하나 고민 중임
기능은 라이브러리로 풀어야지 브라우저 API를 계속 키우는 건 잘못됐다고 봄. 파이어폭스 기능 따라잡기 어렵게 만들려는 구글 의도도 있는 것 같음
라이브러리로는 못 풀림. 텍스트 레이아웃을 제대로 하려면 결국 브라우저 엔진을 JS나 WASM으로 새로 만드는 거라서 엔진 안에서 하는 게 훨씬 쉬움
곡면 요소는 평면 투영 변환으로 근사하면 된다는 식으로 넘어갔다는 얘기가 있음. 마스크로 텍스트 쓰는 순간 선택 하이라이트까지 그려져서 글자가 안 보이는 문제도 생김