Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside a fast CSS engine

hacks.mozilla.org

Post reply on HN
Print view View original

61–70 of 144 posts

Re: Inside a fast CSS engine

#61

Post by taeric »

sanxiyn wrote: post #38
taeric wrote: post #32

Earlier quoted context omitted.

I haven't read it. That snippet just seemed odd to me. The hard parts, in this case, would be in Rust, most likely. I'm assuming that flipping CSS to parallel is not a trivial process. I'm further assuming that there is still some sort of locking mechanism so that you don't fire off two parallel traversals at the same time. Or allow updates during a scan. (Or abort running scans if an update happens?)

Ah yes, parallelism (locking etc) part is entirely handled in generic Rust library (Rayon in this case), and not specific to Stylo at all. Here is where Stylo meets Rayon, https://github.com/servo/servo/blob/master/components/style/... //! Implements parallel traversal over the DOM tree. //! //! This traversal is based on Rayon, and therefore its safety is largely //! verified by the type system. /// A parallel top-d…

I'm curious how well this plays with some of the fancier selectors. Adjacent sibling, in particular.

I'm also curious if this pretty much prohibits ever having a parent selector. I guess you could do a first pass through the styles to remove any DAG nature from them?

Re: Inside a fast CSS engine

#62

Post by rhencke »

taeric wrote: post #60
moosingin3space wrote: post #47

Earlier quoted context omitted.

Do you have a similar concern for all multithreaded programs?

In general, yes. That my computer can do many things is something I take advantage of as a user. The programs should use them to their advantage, but by and large, most programs do not need all of the processing capabilities of my computer, so I expect they should play well together. (Indeed, it takes effort to get the GPU of my computer to help out with anything.)

This is the job of your operating system's scheduler - to divide the limited resource of your computer's CPU time among different competing tasks.

In the modern era, a program cannot take more than its fair share of CPU time - otherwise, a runaway program could easily render your computer nearly unusable. (Linux, macOS and Windows all use preemptive multitasking.)

The way to tell your operating system what you desire prioritized is, on *nix systems, 'nice'.

Re: Inside a fast CSS engine

#63

Post by makmanalp »

moosingin3space wrote: post #42
Vinnl wrote: post #33

Earlier quoted context omitted.

Apart from Kiosk-style systems I think it might also work very well in an Electron-like setting. Supposedly, supporting only new development in the standards (i.e. without having workarounds for every quirk browsers have gathered over the years) is relatively easy, so if you could simply limit yourself to modern techniques to build Electron apps that perform better, that would be great.

You don't even need the whole web platform to build these sort of UIs -- in theory, you could use the WebRender engine to render CSS-box-like UIs. You could avoid some of the weaknesses of the web platform like the memory-heavy DOM. I think this would be an excellent target for a React Native-like framework for desktop, as it would support the full generality of CSS with excellent performance.

Qt has been doing something this for a long while: https://doc.qt.io/qt-5/stylesheet-syntax.html

Re: Inside a fast CSS engine

#64

Post by taeric »

rhencke wrote: post #62
taeric wrote: post #60

Earlier quoted context omitted.

In general, yes. That my computer can do many things is something I take advantage of as a user. The programs should use them to their advantage, but by and large, most programs do not need all of the processing capabilities of my computer, so I expect they should play well together. (Indeed, it takes effort to get the GPU of my computer to help out with anything.)

This is the job of your operating system's scheduler - to divide the limited resource of your computer's CPU time among different competing tasks. In the modern era, a program cannot take more than its fair share of CPU time - otherwise, a runaway program could easily render your computer nearly unusable. (Linux, macOS and Windows all use preemptive multitasking.) The way to tell your operating system what you desire…

I'm well aware of that. I also know that, in general, having to schedule things slows them down. If everything I'm running is trying to schedule something on my entire machine, it is giving my OS more work. Which will, by necessity, be harder to schedule and slow things down.

I'm not necessarily against all of this, but I'm also not eagerly embracing more crap to slow down my machine for no apparent reason.

Re: Inside a fast CSS engine

#65

Post by robin_reala »

kristofferR wrote: post #58

It's such a shame Firefox (including the nightlies) kills my Mac (making most other applications hang/break), since the new versions are otherwise way better than Chrome. Does anyone know what it is about Firefox that makes the rest of my system unable to spawn new processes?

That’s weird. If you’re not attached to your profile you could try resetting it (go to about:support) and see if that fixes it. Otherwise I’d file a bug.

Re: Inside a fast CSS engine

#66

Post by oshepherd »

vvanders wrote: post #26
pcwalton wrote: post #18

Earlier quoted context omitted.

> 1. If I overlap 52 html s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them? Browsers don't typically do very good occlusion culling in general. WebRender aims to change that, by using the hardware Z-buffer. :)

You may want to be careful with that approach. Not all GPUs have the Z-Buffer fillrate to make that approach viable(esp on mobile). I've seen more than a few cases where it was actually faster to turn off Z-Buffering and do the overdraw. More than a few architectures share Z-Buffer bandwidth with other pipelines. On tiled architectures it'll also increase your tile count which can impact your per-drawcall overhead. F…

> Not all GPUs have the Z-Buffer fillrate to make that approach viable(esp on mobile). I've seen more than a few cases where it was actually faster to turn off Z-Buffering and do the overdraw. More than a few architectures share Z-Buffer bandwidth with other pipelines.

Uh, mobile GPUs tend to be way, way ahead of desktop GPUs in Z-Buffer bandwidth (especially in relative terms)

and you can't increase your tile count; there's a fixed number of tiles in the frame buffer (unless you're referring to not drawing some tiles at all - in which case set your scissor rect appropriately. oh, and if you can find out the GPU's tile size round your rectangle up to cover whole tiles)

Re: Inside a fast CSS engine

#68

Post by sanxiyn »

taeric wrote: post #61
sanxiyn wrote: post #38

Earlier quoted context omitted.

Ah yes, parallelism (locking etc) part is entirely handled in generic Rust library (Rayon in this case), and not specific to Stylo at all. Here is where Stylo meets Rayon, https://github.com/servo/servo/blob/master/components/style/... //! Implements parallel traversal over the DOM tree. //! //! This traversal is based on Rayon, and therefore its safety is largely //! verified by the type system. /// A parallel top-d…

I'm curious how well this plays with some of the fancier selectors. Adjacent sibling, in particular. I'm also curious if this pretty much prohibits ever having a parent selector. I guess you could do a first pass through the styles to remove any DAG nature from them?

DOM element has parent and sibling pointer, so there is nothing particularly difficult about adjacent sibling, later sibling, or even parent selector as far as selector matching goes. Avoiding restyling becomes more tricky, but nothing serious. "Parent before child" is for CSS inheritance, not for selector matching.

For not-very-difficult details, read https://github.com/servo/servo/blob/master/components/select... searching for NotMatchedAndRestartFromClosestLaterSibling and HAS_SLOW_SELECTOR_LATER_SIBLINGS.

Re: Inside a fast CSS engine

#69

Post by jamii »

JoshTriplett wrote: post #37
Vinnl wrote: post #33

Earlier quoted context omitted.

Apart from Kiosk-style systems I think it might also work very well in an Electron-like setting. Supposedly, supporting only new development in the standards (i.e. without having workarounds for every quirk browsers have gathered over the years) is relatively easy, so if you could simply limit yourself to modern techniques to build Electron apps that perform better, that would be great.

Absolutely agreed; I'd love to see Servo used as a browser engine for apps. And if you fit within what Servo supports today, you can already do this. I've seen people demonstrate Android applications (written in Rust) that embed Servo.

> I've seen people demonstrate Android applications (written in Rust) that embed Servo.

Do you have a link? I went looking for information about embedding Servo and found nothing.

Re: Inside a fast CSS engine

#70

Post by tedmielczarek »

taeric wrote: post #60
moosingin3space wrote: post #47

Earlier quoted context omitted.

Do you have a similar concern for all multithreaded programs?

In general, yes. That my computer can do many things is something I take advantage of as a user. The programs should use them to their advantage, but by and large, most programs do not need all of the processing capabilities of my computer, so I expect they should play well together. (Indeed, it takes effort to get the GPU of my computer to help out with anything.)

Keep in mind that by parallelizing work the browser can finish the work it's doing faster, which means your CPU can spend more time idle, which is better for power consumption.
Post reply on HN