A new approach to text rendering(blog.atom.io) |
A new approach to text rendering(blog.atom.io) |
Seems like Atom will eventually just be a native app.
"Hey, let's write an editor for a browser. Oh wait, we need a browser for that editor".
Something good will probably come out of this eventually. I mean if they manage to turn electron into a true native cross platform app framework it's nice.
…then you’ll end up back where you started with the JVM.
To be more clear, no one is writhing in their sleep, or bemoaning to their team mates, this: "We have no good way to edit text in the 21st century". No one. At best, it's a nice idea to see "what if" we could build an emacs-like text editor using modern day web technologies, just to see what browsers and HTML5, etc, can do these days, and hey, maybe we will learn something and push the browser technology a bit, too. At worst, it's bunch of people with no other interesting ideas and who need to bring attention to their company.
What's next for this Electron crowd? Let's see if we can build a whole operating system into a browser? Oh wait. That's also been done with a lot of noise and no real-world impact. Well then, what about a new kind of spreadsheet? Or maybe we could do some cool photo-processing using only a TI-84 calculator!
Ugh. I'm so tired of this, and this massive post by the dev team at Atom proves the insanity of all this.
They have spent thousands of man-hours "improving" their text editing rendering for their slow text editor (but hey, we saved time by building it on top of Chrome!), and yet they are nowhere near text-rendering speeds of 40 years ago.
But never mind that. They will continue to plug ahead and write more posts about it. Meanwhile, emacs (and Vim) plug along as always.
How bad is it (to me)? I'll tell you. Even though I alter between Sublime (written in real code and not on 'borrowed' code) and BBEdit sometimes, along with Vim (still learning), and even MacVim (the horrors!)... THIS is how bad it is. It's so bad... that I would use TextEdit to edit code before I used Atom. I promise you. I actually like TextEdit and often use it anyway. I sometimes wish Apple would just add a few tiny improvements (but I'm daydreaming) and I would use it for 90% of files and projects.
But Atom? Like a lot of modern day projects (React, Bootstrap, WordPress, Facebook, etc), it's a total step backwards to reinvent what we already had. So that basically "new" people can come along and play - with less understanding, IMHO.
You'd think that hundreds of thousands of Atom users would convince you that maybe there's something to the editor that works for others if not for you. But nope, all those guys are happy with switching their main IDE to "a total step backwards", for some reason.
Cargo cult is the reason.
Large files, slowish startup, and the like are all special case problems that I can use Sublime for, but until now, the almost subliminal typing sluggishness always drove me away.
Bravo Atom team for making it fast enough. I look forward to continued improvements in this space.
Their integration for TypeScript and GoLang are first class as well. Overall though I held the same excitement for Atom as you did (and I used to use Emacs for everything because I wanted an open editor in my tool belt) I've really come to appreciate the approach and polish of VSCode.
This is a perfect example of why we need parallel restyling. :)
This is exactly what people used to do to optimize drawing in intensive application. You only render the visible area. The entire post explains the supporting actions needed to accomplish this for the browser. Thats why at the end of the text they talk about exploring the use of the canvas.
Here's an application from ~2000 https://www.macintoshrepository.org/2214-vncthing
The actual VNC canvas was offscreen and it would only frequently display the entire thing. Which made it for a long time more efficient than modern vnc clients. I think 2010 it was still better than any other VNC client on macosx. It's by far not an uncommon technique, it's just a pain to do when your target is markup, which is what this post is all about.
Granted, it's more complex because a tile here is a chunk of markup rather than a piece of a pixmap, but still.
An editor that is not "hacked" together on idiotic technologies ("web" "dev"), but a well designed editor, written for performance, on top of the best technology for that specific job.
That's why emacs has existed for decades now.
Is it worth restricting an editor to only styles that don't influence block layout? For example, should it be impossible for a theme to make comment lines taller or shorter? I don't know; it's a tradeoff between performance and flexibility. My feeling is that there's a lot more room to improve the implementation before we have to resort to reducing capabilities, but reasonable people can disagree.
emacs pretty much runs everywhere
And there is a webkit extension to turn emacs into a browser. I wonder how well atom will run in emacs
I use TortoiseGit and IDEs to access Github.
Instead of using web tech to build native apps I think we should focus on improving browsers so that web apps behave more like native apps and have the same capabilities. Browsers should be the cross-platform VM and webassembly is a good step in that direction.
What Atom is referring to by "rendering" here seems to be applying styles to parts of lines. Styling is a higher level concept than vector graphics. Partial styling is something that browsers have wanted to be able to do for a while, but it's quite complex. I've never seen an implementation of partial styling in any UI library, and certainly not in QuickDraw or VNC, which have no CSS-like concept at all.
As I said I wrote about this issue in my blog post. You're trying all sorts of hacks here, because the fundamental issue is that your data structure is the dom and css styling, so everything that other text editors would attach as few byte metadata you used to put in the dom. Which means a simple threeliner that would be a couple of bytes in a proper designed editor, becomes the following beast in atom. Yes it's better now, but the fundamental issue is that you have a weird love relationship to the browser(and no, i'm not judging, whatever floats your boat).
This is even separate from the other problem that is the actual way of dealing with strings in javascript.
<div class="lines" style=
"height: 54px; min-width: 913px; padding-top: 0px; padding-bottom: 0px; top: 0px;">
<div class="line">
<span class="null-grammar text plain">GNU GENERAL PUBLIC LICENSE</span>
</div>
<div class="line">
<span class="text plain null-grammar">hello</span>
</div>
<div class="line">
<span class="text plain null-grammar">what's up</span>
</div>
</div>
<div class="underlayer" style="height: 54px; min-width: 913px; top: 0px;">
<input class="hidden-input" style="top: 0px; left: 0px;" />
<div class="selection" callattachhooks="true">
<div class="region" style="top: 18px; left: 72px; height: 18px; width: 48px;">
</div>
</div>
<div callattachhooks="true">
<div class="bracket-matcher" style="display: none"></div>
<div class="bracket-matcher" style="display: none"></div>
</div>
<div class="spell-check" callattachhooks="true"></div>
<div class="wrap-guide" callattachhooks="true" style=
"left: 640px; display: block;"></div>
</div>That's part of the issue, yes. (The other, and more important, part of the issue is that CSS restyling has to occur in order for the browser to determine the changes that need to be applied to the render tree.) Note that the problem you describe has nothing to do with whether the text is off screen or not.
> Which means a simple threeliner that would be a couple of bytes in a proper designed editor, becomes the following beast in atom.
This is a misleading way to describe it, because the in-memory representation is compressed. Most of the identifiers in the DOM are compressed down to a single pointer, so they're treated as integers and only serialized when necessary. The objects are threaded together into a doubly linked tree, so the textual DOM doesn't actually live anywhere most of the time.
It's as if you took Vim's internal data structures and dumped them out into JSON. They'd be equally bloated and verbose in that format. That doesn't say anything about how efficient Vim is.
The one issue that does matter here is that the styles are currently stored as strings. It's a frequent bottleneck. There is a proposed Typed CSSOM standard [1] that is designed to address this problem. Note, again, that this has nothing to do with whether rendering happens offscreen or not.
Of course not; everyting should be in the same damned monospaced font in a text editor for writing code.
The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really. Variable width text is generally considered easier to read, so why couldn't this also apply to code?
It's not just for neatness; either. Alignment shows where differences are between similar lines. And not necessarily consecutive lines. For instance, if we rapidly flip the editing window back and forth between two buffers showing similar code, we can see the differences as the moving parts in a two-frame animation.
Even in proportional fonts, the digits 0 to 9 get the same width. Why? So that tables of figures will look reasonable.
We don't want 1111.11 looking narrower than the 100.00 in the preceding row.
I want everything to be crisply aligned between lines like:
xr = x * cos(theta) - y * sin(theta);
yr = x * sin(theta) + y * cos(theta);
Because alignment.
>The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really.
Most programmers I know would argue otherwise, including me. Wanna try a poll?
>Variable width text is generally considered easier to read, so why couldn't this also apply to code?
Because it's only considered "easier to read" for general text (books, articles, etc) where you don't need to quickly see anything standing out of the ordinary, and alignment doesn't matter.
Even for traditional uses like accounting, "variable width" is not considered easier to read.
Which give even more credence to what the parent said: that "CSS isn't the right abstraction for styles in a text editor…".
We don't really need the "more power" in an editor, but we could use the less slugginess (and less conceptual overhead) than what CSS offer.
>Is it worth restricting an editor to only styles that don't influence block layout? For example, should it be impossible for a theme to make comment lines taller or shorter?
I'm pretty sure existing editors can do that today too, without CSS. Setting a different font size for comment lines for example.
Based on my limited experience, most text editors don't have correct information for off-screen content anyways, as they tend to do lazy syntax highlighting, which you can sometimes see adjusting while you scroll.
To know how high the editor is, for scroll bars, Sublime Text-style minimaps, etc.
Computing metrics basically requires computing full style information. Doing cascading for any property isn't much more expensive than doing cascading for all properties.
> Based on my limited experience, most text editors don't have correct information for off-screen content anyways, as they tend to do lazy syntax highlighting, which you can sometimes see adjusting while you scroll.
Sure. The way to do that in the Web platform is to do what Atom is doing here: adjust styles only when elements come into view. IntersectionObserver can be useful for that.
It would be great to have a small high-performance subset. The subset needs not have low expression power, though.
That includes font-* and many other attributes that affect text rendering. It isn't possible to know the length of a line of text without computing most of the text layout in modern font rendering. Font family/size/variant, weight, kerning, vertical hinting, traditional horizontal hinting, and LCD subpixel hinting all influence character positions at 1/256 pixel resolution. I highly recommend this[1] paper for a good overview of how this works, which includes an analysis of why Microsoft's older font handling caused serious layout issues (cumulative x-length error) due to over-hinting that forced glyphs onto the pixel grid.
> editors
Monospace fonts usually let you ignore most of these issues, but some (crazy?) people program with proportional fonts[2], and we can't actually ignore Unicode...
(I just use an 80/20 solution: fast - and predictable - Terminus and Dina bitmap fonts most of the time, and let Unicode distort the layout with other stuff as needed)
[1] http://www.antigrain.com/research/font_rasterization/index.h...
Have any of you seen the kind of stuff recent games draw in 16 ms? It's amazing! They sure as hell don't use a work-stealing scheduler in a thread pool for single vertices, though.
Besides, vertices are a much simpler problem than CSS styling. CSS supports hundreds of properties, all of which are parsed and cascaded differently. You have properties that are inherited and properties that are noninherited. You have properties that depend on other properties: for example, any lengths might be specified in terms of ems, which means you have to have resolved the font size first. You have properties that result in completely different render trees, for example "display". You can't effectively throw stream processors like GPUs at the problem (believe me, I've tried).
Could we do better? Sure. But every proposed replacement for CSS I've seen (e.g. Cassowary) has made the complexity problem worse. And most native styling solutions I've seen are usually just very slow implementations of CSS. Separating presentation and markup is just hard, no matter what.
Hi, what other proposed replacements for CSS do you know about? I'm interested in seeing what problems they ran into.
I need to go look at Cassowary again. IIRC it's a solver, so sometimes the layout won't be what you expected, and it's very hard to know what to change such that it does what you want.
For us ordinary folks trying to write good applications that can be maintained by one person and scale reasonably well, there's justifiable reason to jump off this rollercoaster and work in a more humble environment with modest perf/safety tradeoffs and native code executables(e.g. Go, Basic, Pascal).
Where the funding comes from is practically irrelevant, specially if it is a feedback function (i.e., an economic phenomenon, not "phone the legislature to fund more research!!1").
New funding models are good, too, of course. But the tone of the anti-ad camp is asinine.
I disagree. Look up how modern material systems work. There absolutely are analogous things going on to CSS in PBR rendering, shaders, multipass compositing etc.
Is the whole CSS debacle a particularly unlikely concept to yield anything close to a reasonable performing implementation? Sure, but that is because nobody has applied the pressure necessary. People won't play a game that doesn't consistently meet a 30 ms deadline but they seem to happily put up with 3 seconds to final render and call it "amazing".
Also, you are going nuts with the scare quotes. I don't even see what point you are trying to make with those.
That's debatable for the vast majority of them. "Clearly" is a strong word here. And certainly, regardless of how "good" they are, almost none are worth the hit in performance in the most basic of tasks for me.
Extension quality is a bit subjective, sure. But if you are going to claim that emacs extensions are of higher quality because they're written in a more obscure language, then you should give evidence. That is not my experience.
The SV camp has said nothing to convince me otherwise.
I preper phoning the legislature -- more democratic and less private interests-driven.
GPUs work here because games fundamentally operate on a list-like datastructure (the display list), with little interdependence.
Styling on the other hand operates on a tree like datastructure (the DOM), with lots of interdependence.
Cascading isn't something games need at all, and if it was, it could be precomputed. THis can't be done in webpages.
You don't have analogues for tree-structure-based "selectors" and anything more than straightforward property inheritance (e.g. inheritance of transformations in a skeleton) in game engines. CSS is much more complex in this aspect.
The DOM having lots of legacy issues is not the reason styling is slow.
CSS is designed for a lot of flexibility and can't be precompiled, which is why it is slow to style.