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

51–60 of 144 posts

Re: Inside a fast CSS engine

#51

Post by acemarke »

lucideer wrote: post #6

It's great to see any company going into detail about their technical implementation, so I'm extremely hesitant to be critical, but I'm really curious who the target audience for this one particular article is. It's a very very odd mix of language that sounds like it's directed at a very young child and standard technical speak. Not the usual for the Hacks blog. Not to fault the article too much, but I just found the…

Lin Clark's "Code Cartoons" series is intended to take a potentially complex programming topic, and break it down into easy-to-understand terms, using a combination of simpler language and the cartoons. She has previously written Code Cartoons entries on topics such as Flux, Redux, hot module reloading/time travel debugging, and the "React Fiber" rewrite of React. She's also written several entries specifically for the Mozilla Hacks blog on topics such as WebAssembly.

Re: Inside a fast CSS engine

#52

Post by pducks32 »

This is really great of Mozilla. I’m really excited to see such a large rust project used on such a scale; after that I think there will be few doubts it’s a really really impressive language. Also the fact that Mozilla knew this and decided to take such a bold step as rewrite their engine is super cool. I’ve done rewrites and they never go well so hats off to them.

Re: Inside a fast CSS engine

#53

Post by Elv13 »

jancsika wrote: post #4

> 4. Paint the different boxes. Is this really what happens under the hood? 1. If I overlap 52 html s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them? 2. If I overlap 52 s like a deck of cards, does the browser really paint all 52 s before compositing them? 3. In Qt, if I overlap 52 QML rectangles like a deck of cards, does the renderer only paint the parts of the rec…

> 3. In Qt, if I overlap 52 QML rectangles like a deck of cards, does the renderer only paint the parts of the rectangles that will be visible in the viewport? I was under the impression that this was the case, but I may be misunderstanding how the Qt QML scenegraph (or whatever it is called) works in practice.

The rendering part of the question has been answered in another comment, but I would like to point out a couple things.

QML elements are `QObject`s with all the overhead[1] that comes with them. They are created even if they are not visible unless you have some `Loader` or C++ magic to prevent it. A QtWidget `QStyledItemDelegate` only had a single instance for all views/elements that used it. It could scale to millions of "cards" (assuming a QAbstractListModel was used) without any overhead[2].

So even if Qt manage to batch the draws and avoid painting everything, there is still a massive overhead in having such deck. I would suggest using a Loader and keeping only `n` cards loaded. If you want to minimize the performance impact.

[1] Object tree management, signal and slots, `n` connections for each QML expressions (recursively down to each tree leafs), memory impact, slower GC, etc.

[2] Assuming the model had the lazyloading functions implemented.

Re: Inside a fast CSS engine

#54

Post by lambda »

lucideer wrote: post #6

It's great to see any company going into detail about their technical implementation, so I'm extremely hesitant to be critical, but I'm really curious who the target audience for this one particular article is. It's a very very odd mix of language that sounds like it's directed at a very young child and standard technical speak. Not the usual for the Hacks blog. Not to fault the article too much, but I just found the…

Huh, I had the opposite reaction. I thought that it was a very nice, clear article, which is phrased to be approachable by as many people as possible with some amount of technical background.

That technical background may not be as programmers. It may be power users, or web developers, or the like.

And I thought the analogies and illustrations helped out with giving some context that people who aren't systems developers might be missing.

Re: Inside a fast CSS engine

#55

Post by bholley »

sanxiyn wrote: post #22

You may want to actually read this code. You can start by searching "LayoutStyleRecalc" at https://github.com/servo/servo/blob/master/components/layout... . Following is verbatim copy. // Perform CSS selector matching and flow construction. if traversal_driver.is_parallel() { let pool = self.parallel_traversal.as_ref().unwrap(); // Parallel mode parallel::traverse_dom:: ( &traversal, element, token, pool); } else { /…

Note that everything in components/layout is servo-specific and not used by Stylo / Firefox. The code in components/style is shared, and the code that hooks it up to Firefox is in ports/geckolib/glue.rs (specifically Servo_TraverseSubtree).

Re: Inside a fast CSS engine

#56

Post by peoplewindow »

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…

It looks like Rayon is the same thing as Java's ForkJoinPool and parallel streams but with the neat trick (really, Rust's neat trick) that it can statically check that the code is safe to parallelise through the borrow checker.

Re: Inside a fast CSS engine

#57

Post by Manishearth »

Brakenshire wrote: post #17
Manishearth wrote: post #12

Earlier quoted context omitted.

It's a possible eventual goal but we don't have concrete plans or a timeline. Stylo and the like let us get improvements out to users well before we need to deal with that.

Also, all the discussion so far seems to focus on desktop firefox, are these improvements coming to firefox for android, or is that a longer term project, perhaps when servo is ready?

We're hoping to have stylo in 57, and I would expect it to be on android in the next release (58), but no promises.

Basically we intend for it to work eventually on android, but it didn't get prioritized.

Re: Inside a fast CSS engine

#58

Post by kristofferR »

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?

Re: Inside a fast CSS engine

#59

Post by sanxiyn »

peoplewindow wrote: post #56
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…

It looks like Rayon is the same thing as Java's ForkJoinPool and parallel streams but with the neat trick (really, Rust's neat trick) that it can statically check that the code is safe to parallelise through the borrow checker.

Yes, that's a good summary.

Re: Inside a fast CSS engine

#60

Post by taeric »

moosingin3space wrote: post #47
taeric wrote: post #25

Earlier quoted context omitted.

I have similar concerns. I'm all for using my machine to its fullest, but in large, applications like web browsing should be an additional thing I am doing on my computer, not something that thinks it can take the full computer. Though, I have to admit I am also a little torn on this. Yes, browsing is typically done "during compile" or some other task. However, I have also begun doing most of that work remotely so th…

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.)
Post reply on HN