This is actually how Desktop Window Manager (aka "Aero") on Windows and Quartz Compositor on OS X actually work. They're just setup with an orthographic projection and they don't rotate the windows at all.
That was actually a bit of a surprise (though I admit it shouldn't have been) with Primrose. If I pick dimensions for the editor that fit the window's aspect ratio, and don't rotate the view at all, then the editor pane can fill the browser window and it looks very natural.
I am not positive, as I don't have the spec laying in front of me and it's been a long time since I looked, but I'm pretty sure the HTML5 Canvas API is not hardware accelerated at this time. That is how I do the actual rendering of the text, using Text API.
There is another project called fontpath[1] that can read TTF and OTF font files, and another project from the same developer called gl-sprite-text[2] that can render them as bitmaps to textures. I've been considering converting my rendering over to using it. The process would at least be good practice in decoupling the code a bit more, as I think the tokenizer and keyboard system would be useful in other projects as well.
The keyboard code pages aren't yet complete for everyone in the world right now, but I think they go a long way towards making it possible to once and for all make good keyboard interactions in JS. And by completely implementing my own end-around of the browser's own handling, sticking to more of the older primitives, I am actually able to make for more cross browser compatible. I don't know if anyone noticed, but this runs in IE perfectly fine, and I didn't really do anything special to make it so. And if you just run the Canvas on its own, without the WebGL part, it actually runs on some relatively old browsers without any trouble.
That was actually a bit of a surprise (though I admit it shouldn't have been) with Primrose. If I pick dimensions for the editor that fit the window's aspect ratio, and don't rotate the view at all, then the editor pane can fill the browser window and it looks very natural.
I am not positive, as I don't have the spec laying in front of me and it's been a long time since I looked, but I'm pretty sure the HTML5 Canvas API is not hardware accelerated at this time. That is how I do the actual rendering of the text, using Text API.
There is another project called fontpath[1] that can read TTF and OTF font files, and another project from the same developer called gl-sprite-text[2] that can render them as bitmaps to textures. I've been considering converting my rendering over to using it. The process would at least be good practice in decoupling the code a bit more, as I think the tokenizer and keyboard system would be useful in other projects as well.
The keyboard code pages aren't yet complete for everyone in the world right now, but I think they go a long way towards making it possible to once and for all make good keyboard interactions in JS. And by completely implementing my own end-around of the browser's own handling, sticking to more of the older primitives, I am actually able to make for more cross browser compatible. I don't know if anyone noticed, but this runs in IE perfectly fine, and I didn't really do anything special to make it so. And if you just run the Canvas on its own, without the WebGL part, it actually runs on some relatively old browsers without any trouble.
[1] https://github.com/mattdesl/fontpath
[2] https://github.com/mattdesl/gl-sprite-text