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

21–30 of 112 posts

Re: A new approach to text rendering

#21

Post by dang »

Anone33 wrote: post #10

Then ship Servo. It's getting annoying seeing the Servo devs constantly patting themselves on the back about how smart you are and insulting other engines that are actually serving users.

Comments like this are bannable offences and will eventually get your main account banned as well. If you have a substantive point to make, please make it thoughtfully; otherwise please don't comment until you do.

We detached this subthread from https://news.ycombinator.com/item?id=14615504 and marked it off-topic.

Re: A new approach to text rendering

#22

Post by zubat »

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.

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 executables(e.g. Go, Basic, Pascal).

Re: A new approach to text rendering

#24

Post by Manishearth »

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

Re: A new approach to text rendering

#25

Post by Manishearth »

pcwalton wrote: post #14
matthewmacleod wrote: post #11

Earlier quoted context omitted.

That’s unfair. It’s hardly “insulting” to talk about the benefits of a new approach. And as I understand it, Stylo will be shipping in Firefox this year.

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.

Re: A new approach to text rendering

#26

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

Re: A new approach to text rendering

#28

Post by revelation »

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.

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

Re: A new approach to text rendering

#29

Post by justinmk »

zubat wrote: post #22
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.

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

Re: A new approach to text rendering

#30

Post by nicpottier »

pugio wrote: post #26

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

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.

Post reply on HN