Hacker News new | ask | show | jobs
by munificent 1420 days ago
> My initial attempt was based on placing character images, one-by-one, onto a canvas element, but it was horribly sluggish.

I've done web-based terminal-style renders in a number of different ways for my roguelike [1]. I've done both DOM and canvas renderers. I found that the fastest approach to be:

1. Render each glyph to a canvas.

2. Only re-render glyphs that actually changed.

Doing that was much faster than using the DOM. I imagine I could go even faster using WebGL but at this point, I considered the performance good enough.

For anyone interested, my terminal library is written in Dart and is open source:

https://github.com/munificent/malison

[1]: http://munificent.github.io/hauberk/

3 comments

If I would have continued my original approach, I probably would have been able to get something like that working pretty well, but since it is pretty hard to beat Virtual DOM types of approaches, I had no need to try anything else when rendering full screens of text could keep up with key repeat rate.

But of course, the idea of developing a terminal using a standard DOM-centric approach is usually not going to turn out very well... though Google is an exception here with the hterm js library that underlies the terminal output for Chromebooks: https://chromium.googlesource.com/apps/libapps/+/master/hter.... Most Chromebook users will never have the opportunity to put this to use, though people like me who put their Chromebooks in developer mode the first chance they get use it all the time.

Same experience here. Canvas rendering is much faster for terminal apps if done well. I think also VS code uses a canvas for its terminal because its superior performance.
It's been 357 years, and Dart still can't go full screen without a hack like this: https://github.com/munificent/hauberk/blob/master/web/main.d...

https://github.com/dart-lang/sdk/issues/11506 (Jun 25, 2013)

That code is seven years old: https://github.com/munificent/hauberk/commit/2ba2f260baa7004...

I should fix it to use: https://api.dart.dev/stable/2.17.6/dart-html/Element/request...

I just never noticed because it wasn't causing any problems.

I think that must have changed recently (this year, maybe). I know something changed for sure because the method was always there, but it did not return a Future, like it should have, and did not have the optional Map. I don't recall seeing anything in the changelog.

I'll give it a try.