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

31–40 of 112 posts

Re: A new approach to text rendering

#31

Post by panic »

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…

Re: A new approach to text rendering

#32

Post by teleclimber »

pcwalton wrote: post #19
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 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.

Re: A new approach to text rendering

#33

Post by thomasahle »

pcwalton wrote: post #4
Xeoncross wrote: post #3

Earlier quoted context omitted.

How would that work? Breakup the screen into chunks each CPU/GPU renders?

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.

Re: A new approach to text rendering

#34

Post by angry-hacker »

dang wrote: post #21
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.

Dang, you're a coward and snowflake.

Re: A new approach to text rendering

#35

Post by giancarlostoro »

nicpottier wrote: post #30
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 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 not using it at all.

Re: A new approach to text rendering

#36

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

Re: A new approach to text rendering

#37

Post by wbobeirne »

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?

They seem to be adopting a more react native-like mindset of using React to orchestrate what should be happening, but have native code running lower level components. I wouldn't call it "moving away" from the web stack, just having it do more delegating, and less of the nitty-gritty.

Re: A new approach to text rendering

#38

Post by eddyg »

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…

Typing sluggishness in editors is definitely a real / noticeable issue. See https://pavelfatin.com/typing-with-pleasure/

Re: A new approach to text rendering

#39

Post by eddyg »

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…

Typing sluggishness in editors is definitely a real / noticeable issue. See https://pavelfatin.com/typing-with-pleasure/

Re: A new approach to text rendering

#40

Post by jcalabro »

nicpottier wrote: post #30
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 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
Post reply on HN