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

31–40 of 144 posts

Re: Inside a fast CSS engine

#31

Post by sanxiyn »

taeric wrote: post #28
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 { /…

What am I aiming for on this read? I'm assuming the hard parts are swallowed elsewhere, which is good. I'm a little surprised there are two methods for the traversal, depending on the parallel versus sequential. (I'd expect that could have been switched based on the "pool" parameter passed to a single method. No, I don't actually care.)

What do you consider hard parts? The actual magic is that there is no hard parts.

Re: Inside a fast CSS engine

#32

Post by taeric »

sanxiyn wrote: post #31
taeric wrote: post #28

Earlier quoted context omitted.

What am I aiming for on this read? I'm assuming the hard parts are swallowed elsewhere, which is good. I'm a little surprised there are two methods for the traversal, depending on the parallel versus sequential. (I'd expect that could have been switched based on the "pool" parameter passed to a single method. No, I don't actually care.)

What do you consider hard parts? The actual magic is that there is no hard parts.

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?)

Re: Inside a fast CSS engine

#33

Post by Vinnl »

nickpsecurity wrote: post #20
JoshTriplett wrote: post #8

Earlier quoted context omitted.

Ideally it would be both; at a minimum, it should be a full browser engine, suitable for embedding (like WebKit, and unlike Gecko).

I second this for diversity and safety in rendering engines if nothing else. Plus, kiosk-style systems might find good use out of it if it was lean since they can match how they develop their web apps to what Servo supports. Finally, if small and using portable layer on bottom, it could be mixed with self-healing systems like QNX or Minix 3.

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.

Re: Inside a fast CSS engine

#34

Post by rdsubhas »

hamandcheese wrote: post #5
robin_reala wrote: post #2

I turned this on a couple of weeks ago on Nightly and have noticed precisely zero problems, and a really nice little speedup on CSS-heavy sites. Really good to see large chunks of parallelised Rust code start making their way over from Servo to Firefox.

Are there any plans for Servo to be a "real" browser, or will it always be more of a R&D playground for Firefox?

Ideally neither.

The article says We’re swapping in parts from our experimental browser Servo but servo.org says Servo is a modern high-performance browser engine. That's quite a difference.

Would be quite happy with servo being an engine and firefox being the browser (love firefox btw), just like how webkit/blink are the engines powering chrome/safari/opera. with bits and pieces of servo landing into firefox (just like how the CSS engine is landing in now).

I could be wrong though.

Re: Inside a fast CSS engine

#35

Post by taeric »

matthewmacleod wrote: post #29
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…

If that’s what you want to do, the you should ‘nice’ your web browser (or use whatever priority mechanism your environment had available). Artificially limiting performance is absolutely the wrong approach!

It isn't artificially limiting. If my browser didn't need all of my cores to perform, we wouldn't be having this discussion. :)

And I seriously question whether my browser needs this to perform well. I am not completely closed to the idea, but I am highly skeptical.

Re: Inside a fast CSS engine

#36

Post by wlesieutre »

Stratoscope wrote: post #24
ChrisSD wrote: post #10

Earlier quoted context omitted.

Presumably it's trying to bring technical details to the widest possible audience. So some details may fly over the heads of some folk, whereas more domain knowledgeable people might think some parts sound condescending. It's a hard square to circle. I think Chrome tried something similar when they were introducing the chrome browser, although maybe with a different balance.

You're probably thinking of this Chrome comic: https://www.google.com/googlebooks/chrome/

When you said "Chrome comic" I assumed it was this one http://i.imgur.com/bhfYx6R.jpg

Re: Inside a fast CSS engine

#37

Post by JoshTriplett »

Vinnl wrote: post #33
nickpsecurity wrote: post #20

Earlier quoted context omitted.

I second this for diversity and safety in rendering engines if nothing else. Plus, kiosk-style systems might find good use out of it if it was lean since they can match how they develop their web apps to what Servo supports. Finally, if small and using portable layer on bottom, it could be mixed with self-healing systems like QNX or Minix 3.

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.

Re: Inside a fast CSS engine

#38

Post by sanxiyn »

taeric wrote: post #32
sanxiyn wrote: post #31

Earlier quoted context omitted.

What do you consider hard parts? The actual magic is that there is no hard parts.

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-down DOM traversal.
  ///
  /// This algorithm traverses the DOM in a breadth-first, top-down manner. The
  /// goals are:
  /// * Never process a child before its parent (since child style depends on
  ///   parent style). If this were to happen, the styling algorithm would panic.
  /// * Prioritize discovering nodes as quickly as possible to maximize
  ///   opportunities for parallelism.  But this needs to be weighed against
  ///   styling cousins on a single thread to improve sharing.
  /// * Style all the children of a given node (i.e. all sibling nodes) on
  ///   a single thread (with an upper bound to handle nodes with an
  ///   abnormally large number of children). This is important because we use
  ///   a thread-local cache to share styles between siblings.

Re: Inside a fast CSS engine

#39

Post by pcwalton »

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 in our experience. WebRender 1 used to do the rectangle culling on CPU and it ended up being way slower than using the Z buffer on every architecture we tried, including mobile. (Overdraw was even worse.) There are a surprisingly large number of vertices on most pages due to glyphs and CSS borders. Note also that rounded rectangles are extremely common on the Web and clipping those in software is a big pain.

Generally, we are so CPU bound that moving anything to the GPU is a win. We had to fight tooth and nail to make WebRender even 50% GPU bound...

Re: Inside a fast CSS engine

#40

Post by Jasper_ »

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.

Nope, QML draws everything back-to-front with overdraw. From what I can tell, there is an ability to batch things into standard forward-renderer opaque/alpha passes, but that requires setting a flag QSGRenderNode::DepthAwareRendering which no builtin nodes set, from what I can tell, so the whole thing is skipped.

The core renderer code is here: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/s...

Search for m_useDepthBuffer and DepthAwareRendering and follow the trail -- the only use of the flag is from an example about raw OpenGL integration.

Post reply on HN