6 ms·

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

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

Xeoncross 9y ago
How would that work? Breakup the screen into chunks each CPU/GPU renders?
- pcwalton 9y ago
  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.
  - revelation 9y ago
    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.
    - pcwalton 9y ago
      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 were written without parallelism in mind. All of the decisions we make have to be dynamic rather than static, which is why work stealing is especially effective. Besides, vertices are a much simpler problem than CSS styling. CSS supports hundreds of properties, all of which are parsed and cascaded differently. You have properties that are inherited and properties that are noninherited. You have properties that depend on other properties: for example, any lengths might be specified in terms of ems, which means you have to have resolved the font size first. You have properties that result in completely different render trees, for example "display". You can't effectively throw stream processors like GPUs at the problem (believe me, I've tried). Could we do better? Sure. But every proposed replacement for CSS I've seen (e.g. Cassowary) has made the complexity problem worse. And most native styling solutions I've seen are usually just very slow implementations of CSS. Separating presentation and markup is just hard, no matter what.
      - teleclimber 9y ago
        > 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.
        pcwalton 9y ago
        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.
    - zubat 9y ago
      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).
      - justinmk 9y ago
        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.
        zubat 9y ago
        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.
        coldtea 9y ago
        >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"). I preper phoning the legislature -- more democratic and less private interests-driven.
    - Manishearth 9y ago
      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.
      - revelation 9y ago
        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".
        Manishearth 9y ago
        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.
        mianos 9y ago
        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.
        Manishearth 9y ago
        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.
    - Rusky 9y ago
      Games do, however, use job systems just like that for plenty of things that aren't single vertices.
  - thomasahle 9y ago
    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.
    - pcwalton 9y ago
      I'm talking about styling, not layout.
panic 9y ago
I dunno, I'd say it's more an example of why CSS isn't the right abstraction for styles in a text editor…
- pcwalton 9y ago
  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.
  - kazinator 9y ago
    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.
    - capnrefsmmat 9y ago
      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.
    - aninhumer 9y ago
      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?
pjmlp 9y ago
This is a perfect example of why Atom should have been a native application to start with.
- aninhumer 9y ago
  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.
  - pjmlp 9y ago
    As an Emacs fan, not really.
    - foldr 9y ago
      This isn't about emacs. Atom is for people who want an alternative to Emacs. If you only need to know JS and CSS to write an extension, that vastly increases the pool of people who are able to write extensions.
      - LeoNatan25 9y ago
        That "pool" of people "able" to "write" "extensions" is exactly the people you don't want touching your text editor, or any software for that matter. Anyone that has a psychological barrier to take a look at a language that they are not familiar with, let alone a framework or an ecosystem, is not someone that I want being anywhere near the software I use. In an ideal world, I wouldn't want them to be anywhere near the web I visit either, but that is a lost cause.
        foldr 9y ago
        The quality of Atom extensions is good, so that's clearly not true. Also, you are going nuts with the scare quotes. I don't even see what point you are trying to make with those.
twhb 9y ago
Parallel restyling just kicks the can down the road, asking for free perf elsewhere because we still haven't made it fast. What we need is a low-level style interface - .style but for computed, not CSS-integrated, styles - and then to plug into that using CSS where appropriate, or custom JS where appropriate, or even framework JS. Let people control style selection in a real programming language and you've guaranteed that it can now be done in a way that's fast and suitable.
- pcwalton 9y ago
  I don't necessarily disagree, but I'd like to reassess where we are in terms of performance once Typed CSSOM is widely used. Using Typed CSSOM to adjust the "style" properties of individual elements is awfully close to doing what you describe: the difference is that matching and cascading still happens, but the semantics become much simpler if you're adjusting individual styles, and it's not clear to me that most of the overhead can't just be optimized away at that point.

Xeoncross 9y ago

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

pcwalton 9y ago
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.
- revelation 9y ago
  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.
  - pcwalton 9y ago
    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 were written without parallelism in mind. All of the decisions we make have to be dynamic rather than static, which is why work stealing is especially effective. Besides, vertices are a much simpler problem than CSS styling. CSS supports hundreds of properties, all of which are parsed and cascaded differently. You have properties that are inherited and properties that are noninherited. You have properties that depend on other properties: for example, any lengths might be specified in terms of ems, which means you have to have resolved the font size first. You have properties that result in completely different render trees, for example "display". You can't effectively throw stream processors like GPUs at the problem (believe me, I've tried). Could we do better? Sure. But every proposed replacement for CSS I've seen (e.g. Cassowary) has made the complexity problem worse. And most native styling solutions I've seen are usually just very slow implementations of CSS. Separating presentation and markup is just hard, no matter what.
    - teleclimber 9y ago
      > 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.
      - pcwalton 9y ago
        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.
  - zubat 9y ago
    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).
    - justinmk 9y ago
      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.
      - zubat 9y ago
        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.
      - coldtea 9y ago
        >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"). I preper phoning the legislature -- more democratic and less private interests-driven.
  - Manishearth 9y ago
    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.
    - revelation 9y ago
      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".
      - Manishearth 9y ago
        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.
        mianos 9y ago
        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.
        Manishearth 9y ago
        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.
  - Rusky 9y ago
    Games do, however, use job systems just like that for plenty of things that aren't single vertices.
- thomasahle 9y ago
  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.
  - pcwalton 9y ago
    I'm talking about styling, not layout.

panic 9y ago

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

pcwalton 9y ago
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.
- kazinator 9y ago
  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.
  - capnrefsmmat 9y ago
    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.
  - aninhumer 9y ago
    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?

pjmlp 9y ago

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

aninhumer 9y ago
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.
- pjmlp 9y ago
  As an Emacs fan, not really.
  - foldr 9y ago
    This isn't about emacs. Atom is for people who want an alternative to Emacs. If you only need to know JS and CSS to write an extension, that vastly increases the pool of people who are able to write extensions.
    - LeoNatan25 9y ago
      That "pool" of people "able" to "write" "extensions" is exactly the people you don't want touching your text editor, or any software for that matter. Anyone that has a psychological barrier to take a look at a language that they are not familiar with, let alone a framework or an ecosystem, is not someone that I want being anywhere near the software I use. In an ideal world, I wouldn't want them to be anywhere near the web I visit either, but that is a lost cause.
      - foldr 9y ago
        The quality of Atom extensions is good, so that's clearly not true. Also, you are going nuts with the scare quotes. I don't even see what point you are trying to make with those.

twhb 9y ago

Parallel restyling just kicks the can down the road, asking for free perf elsewhere because we still haven't made it fast. What we need is a low-level style interface - .style but for computed, not CSS-integrated, styles - and then to plug into that using CSS where appropriate, or custom JS where appropriate, or even framework JS. Let people control style selection in a real programming language and you've guaranteed that it can now be done in a way that's fast and suitable.

pcwalton 9y ago
I don't necessarily disagree, but I'd like to reassess where we are in terms of performance once Typed CSSOM is widely used. Using Typed CSSOM to adjust the "style" properties of individual elements is awfully close to doing what you describe: the difference is that matching and cascading still happens, but the semantics become much simpler if you're adjusting individual styles, and it's not clear to me that most of the overhead can't just be optimized away at that point.