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

51–60 of 112 posts

Re: A new approach to text rendering

#51

Post by nine_k »

pcwalton wrote: post #43
panic wrote: post #31

Earlier quoted context omitted.

I dunno, I'd say it's more an example of why CSS isn't the right abstraction for styles in a text editor…

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…

CSS gives a lot of power; I'd say too much for a code editor.

It would be great to have a small high-performance subset. The subset needs not have low expression power, though.

Re: A new approach to text rendering

#52

Post by Manishearth »

revelation wrote: post #28
Manishearth wrote: post #24

Earlier quoted context omitted.

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.

Of course they do, modern games are a complex interaction of many different shaders operating on all levels of abstraction on many different classes of runtime data that they compose, renew and adapt many many times in 16 ms. 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. P…

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.

Re: A new approach to text rendering

#53

Post by pcwalton »

cwzwarich wrote: post #47
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…

Why do you need style information for off-screen content in a text editor? It's not like you're going to have JS running that can query the computed style at any point. If it's for scrollbars then you can probably just use an approximation, or compute metrics without actually computing full style information. Based on my limited experience, most text editors don't have correct information for off-screen content anywa…

> Why do you need style information for off-screen content in a text editor? It's not like you're going to have JS running that can query the computed style at any point. If it's for scrollbars then you can probably just use an approximation, or compute metrics without actually computing full style information.

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.

Re: A new approach to text rendering

#54

Post by pdkl95 »

pcwalton wrote: post #43
panic wrote: post #31

Earlier quoted context omitted.

I dunno, I'd say it's more an example of why CSS isn't the right abstraction for styles in a text editor…

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…

> Is it worth restricting an editor to only styles that don't influence block layout?

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

[2] https://news.ycombinator.com/item?id=1056683

Re: A new approach to text rendering

#56

Post by mianos »

Manishearth wrote: post #52
revelation wrote: post #28

Earlier quoted context omitted.

Of course they do, modern games are a complex interaction of many different shaders operating on all levels of abstraction on many different classes of runtime data that they compose, renew and adapt many many times in 16 ms. 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. P…

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.

Re: A new approach to text rendering

#57

Post by flukus »

giancarlostoro wrote: post #35
nicpottier wrote: post #30

Earlier quoted context omitted.

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 be…

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 n…

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.

Re: A new approach to text rendering

#59

Post by Sacho »

flukus wrote: post #57
giancarlostoro wrote: post #35

Earlier quoted context omitted.

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 n…

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?

Re: A new approach to text rendering

#60

Post by Rusky »

revelation wrote: post #16
pcwalton wrote: post #4

Earlier quoted context omitted.

The same way Servo (and the work-in-progress Servo port to Gecko) does it. Compute styles for every DOM node in parallel, using a work-stealing scheduler to distribute nodes among threads in a thread pool. Parent nodes must have their styles computed before children, but other than that constraint it's an embarrassingly parallel problem.

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 do, however, use job systems just like that for plenty of things that aren't single vertices.
Post reply on HN