
A new approach to text rendering - podgib
http://blog.atom.io/2017/06/22/a-new-approach-to-text-rendering.html
======
jtokoph
> But if we’re going so far as to bypass Chrome’s CSS engine, maybe we should
> try to bypass the DOM entirely.

Seems like Atom will eventually just be a native app.

~~~
djfm
Yeah, technology loves cycles.

"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.

~~~
kuschku
> I mean if they manage to turn electron into a true native cross platform app
> framework

…then you’ll end up back where you started with the JVM.

~~~
djfm
Right. We might as well just compile our JS to Java.

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.

------
LorenzoLlamas
Yet another post about "technology improvements" that basically is some
company (Github) with an axe to grind that wants to reinvent the wheel but has
nothing new to offer.

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.

~~~
johnfn
The fact that the only important factor you can think for a text editor to
improve on is text rendering speed shows that you're not really on Atom's
target demographic.

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.

~~~
biocomputation
>> main IDE to "a total step backwards", for some reason.

Cargo cult is the reason.

~~~
johnfn
Yeah but isn't it amazing how cargo cult only applies to the things I don't
like?

------
pugio
I've maintained restrained excitement about Atom for years. A super hackable
editor (what more could a tool-obsessed coder want)... but frustratingly
laggy. This release finally feels snappy enough that I may switch.

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.

~~~
nicpottier
You may also want to give VSCode a go. I haven't used a Microsoft product
(willingly) for decades, but it is a really, really nice and much snappier
than Atom in my experience with things like key echos.

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.

~~~
giancarlostoro
Also as a result of developing VS Code they've made HUGE improvements to
Visual Studio 2017. If anyone had been programming .NET Core with VS 2015 and
switched to VS 2017 you know what I'm talking about. I went from waiting 12
seconds for my project to compile to blinking and Chrome is opening up. Of
course you have to turn off their browser debugging integration, that thing
just sucks up so much dev time if you're not using it at all.

~~~
flukus
My experience with 2017 has been the polar opposite. It runs glacially slow
compared to the 2013 installation on the same machine. The startup time makes
eclipse look lean and mean, it takes over a minute to start.

~~~
Sacho
Have you tried disabling package restore on open?

~~~
flukus
I'm talking about just to start the IDE with no project, opening a project is
time on top of that.

I don't see how it would make a difference though, running "nuget restore"
only takes a second or two.

------
pcwalton
> One frustrating component of the above breakdown is the time spent
> recalculating styles. At this point, it looks like the only way to solve
> this within the current paradigm is to use CSS less and reduce the number of
> selectors in the application, but that’s going to be a hard fought battle
> given the huge number of themes in the ecosystem.

This is a perfect example of why we need parallel restyling. :)

~~~
pjmlp
This is a perfect example of why Atom should have been a native application to
start with.

~~~
geodel
But Github is doubling down on Electron with their next github client on
Mac/Windows etc. Also how would they write blogs about performance if it is
plain old native text editor.

~~~
pjmlp
Also known as CV driven development.

I use TortoiseGit and IDEs to access Github.

------
torrent-of-ions
What a waste of time. A text editor where "more responsive typing" is a
feature is a joke. These problems were solved decades ago on far more limited
hardware.

------
OberstKrueger
This post mentions how the text storage has already been moved to C++, and the
possibility of moving parts of the rendering to C++ as well. Is this part of a
trend for Atom to move at least key components to C++ and away from the web
stack? Or am I off base with this thought and it's been lower-level to begin
with, but these are just optimizations on that?

~~~
maxbrunsfeld
Atom has always had some C++ components, but lately we have moved more core
data structures to C++. This PR, which re-implements the text-buffer in C++,
also landed in the latest beta.

[https://github.com/atom/atom/pull/14435](https://github.com/atom/atom/pull/14435)

~~~
pjmlp
With enough such improvements, Atom will become a native app, as it should
always have been.

------
andrewmcwatters
Though I use Atom on a daily basis, I maintain the opinion that with software
available such as Visual Studio Code, it's painfully obvious that Atom never
had performance as a high priority to begin with.

------
majewsky
Here I was, hoping for an innovative approach to render glyphs in OpenGL or
Vulkan, but they're just dealing with accidental complexity of their platform,
as Alan Kay would put it.

~~~
Scaevolus
Did you see this?
[http://pcwalton.github.io/blog/2017/02/14/pathfinder/](http://pcwalton.github.io/blog/2017/02/14/pathfinder/)

------
benibela
Recently I had to edit test data for a grading platform (People upload their
programs, the programs get called with the test data and they get feedback if
their program works correctly). One test file had 900 000 characters in one
line. Almost 1 MB, not a single linebreak. The grading platform is a webpage
and you upload things through an online editor, so I pasted the file in
Firefox and Firefox crashed.

------
dham
I thought this was going to be a post about fixing the horrible font
rendering. Although I guess that's really a Chromium issue. Still can't switch
to Atom to this day because of the font rendering.

------
rjzzleep
So, we're sort of simulating offscreen drawing by using a virtual dom? I mean
don't get me wrong it's sort of nice that they did this as it's the only thing
they could have done to deal with the issues I wrote in my 2014 blog post, but
that also means that with a lot of effort the web is now able to do what
quickdraw could almost 20 years ago...

~~~
pcwalton
You've always been able to query layout information about DOM nodes that are
off screen. The virtual DOM is used for other reasons.

~~~
rjzzleep
With all due respect, no it's not.

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](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.

~~~
pcwalton
Your confusion (which is understandable) points to the reason why I dislike
the word "render": it's extremely overloaded. Rendering as defined by
QuickDraw (which you alluded to in your above comment) or the VNC client you
linked to is really _painting_ , which browsers only do for areas that are on
screen or close to being on screen. Browsers have performed this optimization
for decades.

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.

~~~
rjzzleep
There is no confusion from my side, I'm not sure why you're trying to use that
strawman, but given your standing in the Rust community it will probably work
anyway.

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>

~~~
dang
Your comments are crossing into personal incivility. We ban accounts that do
that, so please edit such bits out of your posts here, regardless of how wrong
anyone else may be.

------
draw_down
I still really wonder about the approach of using web tech for this editor.
But I haven't tried it in a while so I will do that shortly. I have been
wanting more Github integration in my editor recently, ever since I saw the
Xcode demo.

~~~
noway421
I'd think that the only text editor that web browser is competent to have is
<textarea>

------
linopolus
ViM!

------
y_u_no_rust
Seems like such a wasted effort due to technology choice

