On this page
블로샤퍼에 HTML-in-Canvas를 넣은 이유는 화질이었습니다. 한때 기본 렌더링 경로로도 사용했지만, 지금은 다시 실험 옵션으로 내려와 있습니다.
원래 이 글은 새 렌더러를 소개하고, 좋아진 화면을 보여주고, 장시간 플레이에서도 게임이 더 잘 돌아가게 됐다고 설명하는 글이 될 예정이었습니다. 그런데 테스트 결과가 마지막 주장을 뒷받침하지 않았습니다.
도입 배경
HTML-in-Canvas는 HTML 콘텐츠를 캔버스에 그릴 수 있도록 하는 제안입니다. Chromium에는 플래그를 켜서 사용하는 구현이 들어 있습니다.
블로샤퍼의 인터페이스는 이미 HTML로 구성되어 있습니다. 이 레이아웃은 유지하면서, 완성된 화면이 픽셀로 그려지는 방식을 제어하고 싶었습니다. HIC 경로에서는 화면을 캔버스에 그려 기존 SVG 기반 방식과 다른 경로로 픽셀 렌더링을 처리합니다.
계속 시도해 볼 만한 화질 차이가 있었습니다. 구현하고 검증한 뒤 기본값으로 사용해 볼 이유는 충분했습니다. 문제는 그 화질 개선을 다른 효과의 근거로까지 넓혀 해석하면서 생겼습니다.
동시에 바뀐 런타임과 렌더링 경로
비슷한 시기에 Electron도 42에서 44로 올렸습니다.
런타임과 렌더링 경로가 함께 바뀐 것입니다. 새 빌드로 스팀덱에서 장시간 실행해 보니, 예전에는 이펙트가 나올 때 나타나던 버벅임이 관측되지 않았습니다.
그 조건에서 새 빌드가 더 잘 돌아갔다고는 말할 수 있었습니다. HIC 덕분이라고는 말할 수 없었습니다. 이후 Electron 44에서 HIC를 끄고 돌린 경우에도 예전의 프레임 드롭이 나타나지 않았습니다. 개선의 공로를 HIC에 돌릴 근거는 약해졌고, 런타임 업그레이드 쪽을 보게 됐습니다.
HIC가 메모리 누수를 잡았다거나 장시간 실행의 안정성을 해결했다고 쓸 근거는 없었습니다.
렌더링 효과가 다른 성능 비교
HIC를 켰다 끄며 성능을 비교하는 데는 다른 문제도 있었습니다.
당시 구현에서는 HIC가 켜지면 일부 SVG 효과를 생략했습니다. CRT 스타일의 화면 왜곡 효과와 픽셀화 필터가 그 경로에서는 적용되지 않았습니다.
그러면 HIC를 켠 쪽이 더 부드러워 보여도, 연출 일부가 빠져서 할 일이 줄어든 결과일 수 있습니다. 같은 이미지를 더 효율적으로 그렸다고 볼 수 없는 비교였습니다.
프레임 시간을 재기 전에 두 경로가 동등한 내용을 그리고 있는지부터 확인해야 했습니다. 이 확인을 빼면 성능 숫자 뒤에 게임의 화면 차이가 숨어 버립니다.
2026년 10월 추가 검증: 정상 렌더링 루프와 빈 초상
10월에 Electron 45.1.0을 검증하면서 HIC도 다시 확인했습니다. Apple M4 환경에서 테스트한 macOS 빌드는 HIC를 켜면 캐릭터 초상과 중첩된 캔버스 콘텐츠가 빈 화면으로 나왔습니다.
낮은 수준의 확인 결과 중에는 정상인 것도 있었습니다. 초상의 WebGL 컨텍스트는 존재했고, 컨텍스트가 유실됐다는 상태도 아니었습니다. HIC의 렌더링 루프도 돌고 있었습니다. 그렇다고 초상이 화면에 그려졌다는 뜻은 아니었습니다.
실제 출력 화면을 확인하는 검사가 이 실패를 잡았습니다. API가 있는지, 컨텍스트가 만들어지는지, 그리기 호출이 계속되는지는 질문의 일부에만 답합니다. 게임에서는 캐릭터가 화면에 보여야 합니다.
이번 재검증으로 확인한 것은 해당 구성에서 렌더링이 실패한다는 사실입니다. 근본 원인이 Chromium에 있는지, 제 사용 방식에 있는지까지 가려낸 것은 아닙니다.
2026년 10월 30일 기준 상태
블로샤퍼는 Electron 45.1.0으로 올라갔습니다. HIC는 기본적으로 꺼진 실험 옵션으로 남아 있고, 렌더링 문제도 아직 열려 있습니다.
화질상의 이점은 계속 살펴볼 이유가 됩니다. 하지만 캐릭터 초상이 비어 버릴 수 있는 경로를 모든 플레이어에게 기본으로 제공할 근거는 되지 못합니다.
당분간 기본값은 기존 렌더러입니다. 다음에 다시 비교할 때도 연출 조건을 맞추고, 실제 게임 화면을 확인하고, 무엇을 바꿔서 결과가 달라졌는지 설명할 수 있어야 합니다.
HIC 구현은 다음에 다시 시험할 수 있도록 게임에 남겨두었습니다. 플레이어가 기본으로 사용하는 경로는 아닙니다.
