The assertion that gpu is required for good text rendering caught me off guard. I can't claim it is wrong, but it does feel like it should be wrong.
Sublime Text 3 still exclusively uses CPU rendering. Unless you're working with really high resolutions (think 8k), CPU rendering is plenty fast.
Xi-Editor Retrospective
121–130 of 162 posts
Re: Xi-Editor Retrospective
#122Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?
Interesting juxtaposition of client/server with modernity. It seems really obsolete, in reality. Every kind of client/server UI system has been tried before. 20 years ago the idea that UI elements would run in the display server while sending commands to model/controller backends (over CORBA!) had a lot of traction. Of course, the idea sucks, so all of these projects are dead and buried. People think something valuab…
Re: Xi-Editor Retrospective
#123Too much over-engineering here. It is always better to start with simple, dumb and reliable code, with minimal architecture, and then grow organically. With experience, I tend to write the less smart code possible, I felt in love with the power of brute-forcing everything.
> With experience, I tend to write the less smart code possible I'm always amused by the hn threads patting ourselves on the backs for in depth technical discussions[1], when so often the top comments are basically non-specific thought leader tweets. For those that got this far, the article is well worth reading about a design space with difficult tradeoffs, and there are comments actually engaging with the content b…
Re: Xi-Editor Retrospective
#124> CRDT as a mechanism for concurrent modification.
i am genuinely wondering if concurrent modification is really, truly needed ?
Re: Xi-Editor Retrospective
#125The same thing I experienced. Text rendering performance is terrible with Cocoa, and even worse with Win32. Calculating text width is an order of magnitude slower than with FreeType.
That's why for my UI framework I also went from using "native" APIs to custom GPU rendering.
Re: Xi-Editor Retrospective
#126Re: Xi-Editor Retrospective
#127Earlier quoted context omitted.
The main reason is that the parsing model is applying a whole bunch of unanchored regexes to the unparsed remainder of the line one after another until one matches, then starting again for the next token. This means each token parsed can require dozens of regex matches over the same characters. Hm but why can't you just OR them together? That is perfectly fine with a regular language engine. For example, I OR togethe…
Two reasons: captures, and it needs to know which of the regexes matched. I meant to but forgot to mention in my original comment that the reason Sublime's built-in highlighter is the fastest is they wrote a custom regex engine which basically does the equivalent of or-ing them together but unlike all other regex engines handles captures and information about which one matched properly while doing so. The custom engi…
Re: Xi-Editor Retrospective
#128Earlier quoted context omitted.
Sublime Text 3 still exclusively uses CPU rendering. Unless you're working with really high resolutions (think 8k), CPU rendering is plenty fast.
Doesn’t Sublime Text have an option somewhere to use a GPU buffer or something once your resolution passes some reasonable limit (I think 2560)? What does that do?
// Mac only. Valid values are true, false, and "auto". Auto will enable
// the setting when running on a screen 2560 pixels or wider (i.e., a
// Retina display). When this setting is enabled, OpenGL is used to
// accelerate drawing. Sublime Text must be restarted for changes to take
// effect.
"gpu_window_buffer": "auto",Re: Xi-Editor Retrospective
#129Aww, this is really disappointing to hear but an excellent read nonetheless. I always had Xi in the corner of my eye as a very interesting way to make a text editor that had a lot of good things going for it: modularity, native UI, speed…I think if it worked out it would have been really great. It's really sad to hear that it didn't. Thank you, Raph and the rest of the Xi contributors, for working on it for all these…
Re: Xi-Editor Retrospective
#130This was solving problems nobody really has, so its fate was predictable. Here's what I think could take off like a rocket: a VSCode-like experience that runs completely in terminal, and therefore does not require a "remote" of any kind. Better yet if it takes most of the same plugins, to reuse the immense amount of work people have done there (and are not going to re-do for some hotshot new editor). Note how none of…
I don't want to speak too much for raphlinus here [1], but I don't think it was ever the goal to make an editor that gets a lot of downloads like a startup pitching a product. All the things you've listed are non-goals, or at least lower-priority goals. The goal was to make an editor based on sound technology principles, and that included investigating said technology principles. It turned out some of those principle…