Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new approach to text rendering

blog.atom.io

Post reply on HN
Print view View original

61–70 of 112 posts

Re: A new approach to text rendering

#61

Post by flukus »

Sacho wrote: post #59
flukus wrote: post #57

Earlier quoted context omitted.

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.

Have you tried disabling package restore on open?

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.

Re: A new approach to text rendering

#62

Post by Manishearth »

mianos wrote: post #56
Manishearth wrote: post #52

Earlier quoted context omitted.

Shaders are a completely different thing from styling (cascading). 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.

Game engines are pretty much completely sitting on complex tree structures. Way more than the DOM. The main reason the DOM all looks so tricky is it is a hack on a hack on a hack. A lot of game engines have been rewritten from scratch many times over.

Yes, trees are involved in games too, but not at the level I'm talking about.

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.

Re: A new approach to text rendering

#63

Post by maxbrunsfeld »

OberstKrueger wrote: post #36

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?

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

Re: A new approach to text rendering

#64

Post by djfm »

jtokoph wrote: post #49

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

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.

Re: A new approach to text rendering

#65

Post by pjmlp »

pcwalton wrote: post #2

> 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. :)

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

Re: A new approach to text rendering

#66

Post by pjmlp »

maxbrunsfeld wrote: post #63
OberstKrueger wrote: post #36

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?

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

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

Re: A new approach to text rendering

#67

Post by intoverflow2 »

Manishearth wrote: post #24
revelation wrote: post #16

Earlier quoted context omitted.

Work-stealing scheduler, thread pool? What is going on here? 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.

Games are a completely different problem space. "styling" is a concept that games don't have; games don't deal with deciding which thing has which style at runtime. Browsers do, because they are just given CSS and have to handle the cascading and assigning of styles on their own.

> "styling" is a concept that games don't have

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.

Re: A new approach to text rendering

#68

Post by aninhumer »

kazinator wrote: post #45
pcwalton wrote: post #43

Earlier quoted context omitted.

CSS is more powerful than anything that popular native text editors can do. As far as I'm aware, in native text editors, generally, style can't influence (block-direction) layout, and that's why they can get away with determining what's visible before restyling. Once you have styles that can influence layout, this dependency is reversed, so any native text editor will have to restyle off-screen lines just as a browse…

Should it be impossible for a theme to make comment lines taller or shorter? Of course not; everyting should be in the same damned monospaced font in a text editor for writing code.

Why does code need to be monospaced? I feel like the only reason we all do it is that it's always been done like that so it feels wrong not to.

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?

Re: A new approach to text rendering

#69

Post by aninhumer »

pjmlp wrote: post #65
pcwalton wrote: post #2

> 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. :)

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

Eh, I feel like the web platform as allowed it to be massively extensible in a much more convenient and familiar way than a lot of other editors. I tried it for a little bit and it felt like the "Sublime Text but more open and flexible" that I really wanted. If they can work out a way to improve performance without sacrificing too much of that, it would be great.

Re: A new approach to text rendering

#70

Post by pjmlp »

aninhumer wrote: post #69
pjmlp wrote: post #65

Earlier quoted context omitted.

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

Eh, I feel like the web platform as allowed it to be massively extensible in a much more convenient and familiar way than a lot of other editors. I tried it for a little bit and it felt like the "Sublime Text but more open and flexible" that I really wanted. If they can work out a way to improve performance without sacrificing too much of that, it would be great.

As an Emacs fan, not really.
Post reply on HN