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

41–50 of 112 posts

Re: A new approach to text rendering

#41

Post by pcwalton »

thomasahle wrote: post #33
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.

In css sibling nodes can certainly affect the position of each other, but that might be ok. A harder problem will be siblings that "run in" to each other, and overlap in various ways.

I'm talking about styling, not layout.

Re: A new approach to text rendering

#42

Post by nstart »

Manishearth wrote: post #25
pcwalton wrote: post #14

Earlier quoted context omitted.

I can't reply to the above comment because it's dead (and no, I didn't flag it), but you can try parallel styling out by building Firefox Nightly with --enable-stylo and enabling the preference in about:config.

It should be a pref switch in the next nightly on 64 bit linux and windows, fwiw.

that's good to know. I'm actively keeping up with FF updates (stable) and it'll be good to try the nightly updates too

Re: A new approach to text rendering

#43

Post by pcwalton »

panic wrote: post #31
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. :)

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

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.

Re: A new approach to text rendering

#44

Post by pcwalton »

teleclimber wrote: post #32
pcwalton wrote: post #19

Earlier quoted context omitted.

Games are at an advantage because they can do a lot of up-front processing. They can statically schedule their content based on knowledge of the hardware, and programmers can and do even tell the artists to tailor their content directly to the system. Conversely, on the Web, we can't do any of this: we have no idea what the content is going to be like until we receive it, and we have to handle specifications that wer…

> But every proposed replacement for CSS I've seen (e.g. Cassowary) has made the complexity problem worse. 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.

Cassowary was admittedly a bad example, because it's a layout algorithm rather than a style system. But I've seen folks suggest that we just replace CSS with TeX, for example. Using TeX would make this problem a lot worse, because styling TeX involves expanding textual macros. You would lose any possibility of parallelism, ever.

Re: A new approach to text rendering

#45

Post by kazinator »

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…

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.

Re: A new approach to text rendering

#46

Post by chillee »

jcalabro wrote: post #40
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…

I'm not sure why it was, but I couldn't use vs code because all the vim plugins available made it lag like crazy (~1sec per cursor movement). It's also worth noting that it only lagged on my work machine, not at all sure why :/ it was fine on my personal machine but it dissuaded me from switching because of it

All the vim plugins? That's bizarre. VSCodeVim had a bug if you were using `useSolidBlockCursor` that would slow it down, but I'd be surprised if all the vim plugins had the same bug.

Re: A new approach to text rendering

#47

Post by cwzwarich »

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…

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 anyways, as they tend to do lazy syntax highlighting, which you can sometimes see adjusting while you scroll.

Re: A new approach to text rendering

#48

Post by zubat »

justinmk wrote: post #29
zubat wrote: post #22

Earlier quoted context omitted.

Or to put it in other words: browser technology is asked to do so much that they had to go invent a new language to keep up. So that they could serve ads. 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…

The "so they could serve ads" meme is facile, reductionist, sophomoric. Actually, the fact that Google et al. were able to identify a profit function that could be optimized to fund the last 15 years of technology is an incredible achievement. In ~2000 it wasn't at all obvious that the internet could find a robust funding model. Where the funding comes from is practically irrelevant, specially if it is a feedback fun…

A realpolitik view of tech only holds under the assumption that any new technology is good technology. It allows nothing to balance or sustainability, and I believe the trajectory of the Web is unsustainable and therefore fundamentally doomed despite its near-term wonders.

The SV camp has said nothing to convince me otherwise.

Re: A new approach to text rendering

#50

Post by capnrefsmmat »

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.

My Emacs Org-mode setup already has larger font (and taller lines) for headings, so this isn't too crazy. Not everything in a text editor is code; some of it is text.
Post reply on HN