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

21–30 of 144 posts

Re: Inside a fast CSS engine

#21

Post by dmitriid »

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…

AFAIK this is a common problem in rendering, be it CSS or games: how do you not render something that's not currently visible on screen. There are all sorts of tricks to calculate the "render only this" set as quickly as possible.

Re: Inside a fast CSS engine

#22

Post by sanxiyn »

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 {
      // Sequential mode
      sequential::traverse_dom::(
          &traversal, element, token);
  }

Re: Inside a fast CSS engine

#23

Post by tannhaeuser »

Congrats! Beyond the CSS engine itself, I also very much appreciate inside development stories like these. I'd also like to read a meta-story about the development efforts in terms of time spent, prior knowledge required etc., and CSS spec feedback, with a reflection on the complexity of implementing CSS from scratch.

Re: Inside a fast CSS engine

#24

Post by Stratoscope »

ChrisSD wrote: post #10
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…

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/

Re: Inside a fast CSS engine

#25

Post by taeric »

c-smile wrote: post #19

Parallel processing demonstrates benefits only if you have physical cores to run code on them. If just one core is available for the app then parallel processing is a loss due to thread preemption overload. Is there any real life examples of achieved speedup?

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 that I can save battery on my laptop. To that end, it is now less of a concern on preserving cores for my tasks that actually need it.

Re: Inside a fast CSS engine

#26

Post by vvanders »

pcwalton wrote: post #18
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…

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

For low-tri things like UI you're better off doing the rect-culling yourself in software(ideally on another thread) and only falling back to the Z-Buffer if you have actual 3D transforms that need per-pixel culling.

Re: Inside a fast CSS engine

#27

Post by sanxiyn »

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 { /…

Hm, you may be lost if you don't have Rust IDE handy to jump around. Web cross reference for Rust code navigation is in development, but until that is ready, the next step is https://github.com/servo/servo/blob/master/components/layout...

parallel and sequential traverse_dom is generic traversal code which calls DomTraversal::process_preorder etc to do actual work. Here is lightly edited code:

  impl DomTraversal for RecalcStyleAndConstructFlows
      where E: TElement,
            E::ConcreteNode: LayoutNode,
            E::FontMetricsProvider: Send,
  {
      fn process_preorder(&self, traversal_data: &PerLevelTraversalData,
                             context: &mut StyleContext, node: E::ConcreteNode,
                             note_child: F)
          where F: FnMut(E::ConcreteNode)
      {
          if !node.is_text_node() {
              let el = node.as_element().unwrap();
              let mut data = el.mutate_data().unwrap();
              recalc_style_at(self, traversal_data, context, el, &mut data, note_child);
          }
      }
  }

Re: Inside a fast CSS engine

#28

Post by taeric »

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

Re: Inside a fast CSS engine

#29

Post by matthewmacleod »

taeric wrote: post #25
c-smile wrote: post #19

Parallel processing demonstrates benefits only if you have physical cores to run code on them. If just one core is available for the app then parallel processing is a loss due to thread preemption overload. Is there any real life examples of achieved speedup?

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!

Re: Inside a fast CSS engine

#30

Post by robin_reala »

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?

Stylo isn’t available on Firefox for Android yet but you can track this bug; they’d like to enable it “sooner rather than later” https://bugzilla.mozilla.org/show_bug.cgi?id=1366049
Post reply on HN