On this page
I added HTML-in-Canvas to Blosharper for its rendering quality. It became the default, then went back behind an experimental setting.
The original plan for this post was to explain the new renderer, show the visual improvement, and describe how it helped the game run better during long sessions. The tests did not support that last part.
Why I tried it
HTML-in-Canvas is a proposal for drawing HTML content into a canvas. Its implementation is available behind a flag in Chromium.
Blosharper already has an HTML-based interface. I wanted to keep that layout while controlling how the finished screen became pixels. My HIC path draws the screen into a canvas, giving the game's pixel rendering a different route from the existing SVG-based approach.
There was a visual improvement worth pursuing. It was enough to implement the path, test it, and try it as the default. The problems appeared when I started treating that improvement as evidence for other benefits.
Two changes, one apparent improvement
Around the same time, I moved from Electron 42 to Electron 44.
That meant two substantial things changed together: the runtime and the rendering path. In long Steam Deck sessions, an old symptom stopped appearing: effects that had previously caused stuttering were running more smoothly.
I could say the new build behaved better in those sessions. I could not say HIC caused it. Later runs with Electron 44 and HIC disabled also avoided the old frame drops. That weakened the case for crediting HIC and pointed toward the runtime upgrade instead.
I had no basis for saying HIC fixed a memory leak or solved long-session stability.
The comparison was not drawing the same thing
There was another problem with comparing HIC on and off.
In the implementation at the time, enabling HIC skipped some SVG effects. A CRT-style distortion effect and a pixelation filter were not applied on that path.
So an apparently smoother HIC run could be doing less work because part of the presentation was missing. It was not necessarily producing the same image more efficiently.
Before comparing frame times, I needed to check whether both paths were actually rendering equivalent content. Without that, a performance number would hide a visual difference that mattered to the game.
October 2026 update: the renderer was running, but the portraits were missing
I revisited HIC when testing Electron 45.1.0 in October. In a macOS build tested on Apple M4 hardware, enabling HIC left character portraits and nested canvas content blank.
Some of the lower-level checks looked fine. The portrait's WebGL context existed and did not report itself as lost. The HIC rendering loop was active. Those facts did not establish that the portrait reached the screen.
The visual checks caught the failure. Detecting an API, creating a context, or seeing draw calls advance only answered part of the question. The game still needed to display its characters.
The retest established a rendering failure in that configuration. It did not establish whether the underlying cause belonged to Chromium or to my use of it.
Status as of October 30, 2026
Blosharper has moved to Electron 45.1.0. HIC remains an experimental option, disabled by default, with the rendering issue still open.
The visual benefit is still a reason to keep investigating. It is not enough to make players use a path that can leave character portraits blank.
For now, the existing renderer stays the default. Any future comparison needs equivalent effects, checks of the actual game screens, and enough separation between changes to explain the result.
The HIC implementation remains in the game so I can test it again. It is not the default players use.