It’s a fair assumption that it would, but that wasn’t my experience in practice.
Browsers are surprisingly efficient renderers. So I can use a lean AOT language for most of the heavy lifting and then just use the webview for the final painting to screen.
The final runtime isn’t actually any more CPU nor memory hungry than when I was having to store images and font atlases in GPU memory and writing to the frame buffer directly via SDL. And as a benefit of the switch, I get a richer library of widgets to draw, far fewer rendering glitches due to edge cases in fonts, graphics drivers, and a plethora of other hard-to-debug problems.
The original plan was to support both WebKit and SDL frontends (like how libghostty works) but the webview was such an accelerant on productivity and with so few drawbacks that i quickly dropped SDL support and went all in with webviews.
Browsers are surprisingly efficient renderers. So I can use a lean AOT language for most of the heavy lifting and then just use the webview for the final painting to screen.
The final runtime isn’t actually any more CPU nor memory hungry than when I was having to store images and font atlases in GPU memory and writing to the frame buffer directly via SDL. And as a benefit of the switch, I get a richer library of widgets to draw, far fewer rendering glitches due to edge cases in fonts, graphics drivers, and a plethora of other hard-to-debug problems.
The original plan was to support both WebKit and SDL frontends (like how libghostty works) but the webview was such an accelerant on productivity and with so few drawbacks that i quickly dropped SDL support and went all in with webviews.