Add Canvas-based WASM display

[edwanji]

Separate webfiles into DOM (the original implimentation) and Canvas. Canvas-based display is much faster for larger screen sizes.
Modified wscreen.go for better support of Canvas display.
Cursor position is indicated by an additional AttrMask flag. This flag is not exposed outside of the tcell package.
Initial screen size is passed into tcell by environment variables.
Optional "fitwindow" variable in tcell.js activates auto-sizing the terminal to fit the browser window.
Updated DOM version of tcell.js to conform with the new interface.

[gdamore]

So I'm not a web technologies expert here. Why do we need both DOM and Canvas here? It seems like having two different implementations would be confusing, but I don't understand the merits.

If we need both, then I'd like to see a rationale -- and there should be details in README files to help others who might want to use these decide which to use.

It looks to me like the canvas implementation doesn't have any support CSS... which seems unfortunate -- I would imagine that callers would like to be able to provide or override default values for the fonts, sizes, colors, and so forth.

[edwanji]

I am absolutely not a web technologies expert either. I found that the original DOM implementation became unusable on my system when the screen size was enlarged beyond 24x80. So I taught myself how to use Canvas, and wrote that implementation. Since I don't know if there is some advantage to DOM (the ability to use CSS is an obvious one) I left the implementation as a choice.
I don't know if it's possible to use CSS for Canvas. I doubt it is since it's drawing characters manually instead of using the HTML render. I suppose I could interrogate the CSS to retrieve the font/color information...

[gdamore]

When you say became unusable... I assume you mean that the screen didn't grow to more than 80x24, right? It seems like it should be possible to resolve that even within the DOM, but again I'm not an expert here. I think it should also be possible to use CSS within Canvas, but I lack the specific knowledge.

[gdamore]

I believe a better solution would be to add resizing support to the DOM version.

I haven't had time to fully code this up, but I think there is a "resize" event that we can add a listener for, and you can create a div that is resizable to hold the element. (Or possibly the pre could just be made resizable.

If I can find time later to work this I will, but I'd really prefer to have someone familiar with JS and HTML5 take a crack.

[edwanji]

Originally, I was just going to make changes to resize the screen. When I say "unusable", I am talking about the screen update speed. At the 80x24, the DOM is very responsive. When enlarging it, it slows down very quickly. At what I consider a reasonable resolution for my purpose (say 160x48) the screen would freeze for almost a full second before making an update, even if it was just a single cell. I made some changes to try to speed it up, but it didn't help.
There might be a way to make the DOM implementation more responsive, but I don't know how to do it.

I'd really prefer to have someone familiar with JS and HTML5 take a crack.

It would be great if someone who actually knows what they're doing would look into the responsiveness issue. (For all I know, it could just be a problem with my browser/CPU.) For the canvas implementation, I was just learning as I went and got something that worked well for my particular case.

[gdamore]

I'm surprised that the DOM updates are that bad. Maybe there is some double buffering or something that Canvas does that DOM doesn't?

[gdamore]

For the record, I took a look at the DOM stuff and I suspect that the problem with the DOM being so terrible is that we are using spans for every single character cell on the screen. While in some pathological that would be needed, in the vast majority of real world scenarios that is not true. Smarter span handling would allow much more efficient handling, I think.

I am thinking of fixing that. But I'm also contemplating whether we should just implement on top of xterm.js. I think that might be superior still, and it offers both canvas / OpenGL and DOM modes of operation.