GPU acceleration isn't going to make a difference here. Bespin started as Canvas-based and moved to Ace's DOM based rendering because there wasn't a significant performance advantage to keeping it on canvas.
Mozilla and the ajax.com guys have put a significant amount of effort into this area (the current system is the third rewrite for the Mozilla guys) and both teams had a pretty good set of js hackers. I disagree with some of the decisions made (mostly due to scope and what I think is important vs what they think and my background in writing several Vim plugins) but the decisions weren't made from technical ignorance or not being willing to experiment with non-DOM backends. If you aren't familiar with what they're doing, you're going to spend most of your time rediscovering pain points. The simplest example I know of is that there isn't a good way to figure out exactly what the user typed other than having them type into a hidden text field and reading the results back. The obvious approaches seem to work for US/EU keyboards but fall apart on the CJK family.
Yeah, there isn't a very good interface between the events passed to Javascript and IMEs yet... and this causes the headaches with non US/EU input. I had the hidden text field method down as a last ditch workaround.
I do plan on learning as much as possible about the current attempts to do similar projects. But I feel that the current options do not adopt enough of a "get out of the way" approach for me. I'm hoping to write an alternative for those who don't want a browser based eclipse. I've been poking at WebGL for this and I really do think it can help... but I also understand that I may be eating my words here shortly.
Their Orion project takes a very different approach of integrating services from all over the web and includes GitHub integration out of the box. It does have a server side part, but it also has a ton of client side code (that's all BSD-licensed!)
Their rendering is based on contentEditable, which means that it handles RTL text better than anything else and is likely to be accessible to disabled people. (For these reasons, we're working on including this editor in Firefox!)
As far as straight up programming editor functionality goes, Ace is hard to beat. It's got extensible keybindings (someone has built vi bindings, emacs is also possible). And don't let the DOM part throw you off... keep in mind that a canvas is DOM also – you could draw a canvas minimap if you wanted to.
And, as others state, if you really want to use canvas for rendering, you can pick up the Bespin code. The last version produced didn't have the server side and all of that stuff.
I think JS-based editors are the future, but I don't think brand new editing components are where the action is at: the action is in the stuff around the editing component.
(ObDisclaimer: My biases come from having worked on Bespin and Mozilla's other developer tools...)
I would strongly urge you to consider starting out with ACE instead of relearning the lessons learned by those who came before you. ACE is a well-tested, relatively-performant, extendable-by-design basis for any web-based text editing project. I followed the mailing lists for a long time, and it was not a trivial decision for Mozilla to abandon their efforts with Bespin in favor of ACE, but it was a necessary one.
Mozilla and the ajax.com guys have put a significant amount of effort into this area (the current system is the third rewrite for the Mozilla guys) and both teams had a pretty good set of js hackers. I disagree with some of the decisions made (mostly due to scope and what I think is important vs what they think and my background in writing several Vim plugins) but the decisions weren't made from technical ignorance or not being willing to experiment with non-DOM backends. If you aren't familiar with what they're doing, you're going to spend most of your time rediscovering pain points. The simplest example I know of is that there isn't a good way to figure out exactly what the user typed other than having them type into a hidden text field and reading the results back. The obvious approaches seem to work for US/EU keyboards but fall apart on the CJK family.