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

41–50 of 144 posts

Re: Inside a fast CSS engine

#41

Post by peoplewindow »

Manishearth wrote: post #12
hamandcheese wrote: post #5

Earlier quoted context omitted.

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

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.

I have to say, that seems like exactly the right approach and it's seriously impressive to see what you're doing.

I remember the original Mozilla, how it started out as a total rewrite of Navigator. It took years to reach feature parity and Navigator lost all of its market share in that time.

Being able to do refactorings like this, and introduce a whole new language at the same time, is seriously impressive engineering. Bravo.

Re: Inside a fast CSS engine

#42

Post by moosingin3space »

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.

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.

Re: Inside a fast CSS engine

#43

Post by kzrdude »

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?

Servo has their argument from power saving as well; do the work across many cores and go back to cpu power saving modes faster.

Re: Inside a fast CSS engine

#44

Post by lucideer »

rbanffy wrote: post #15
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…

Open source depends on people wanting to work on it. Firefox is a very intimidating beast under the hood. Making it interesting is a vital important goal.

I get that, and that's exactly what the Hacks blog is for (it has always done this masterfully). The recent posts on Hacks and Mozilla Tech on Medium have done this really well I think.

I don't think the tone here necessarily does anything for generating interest though. This is highly subjective, but at least for me it made for a jarring read and I lost interest pretty quickly. As I said above, I respect the intent behind the article, but I just found it very odd.

Re: Inside a fast CSS engine

#45

Post by moosingin3space »

aembleton wrote: post #3

The writeup is inspiring. I found it very clear and yet reasonably in depth. It helps me to understand how much work modern browsers are doing. Also, excellent use of Rust.

> excellent use of Rust

I should hope so! It was one of the major motivators behind Mozilla's stewardship of Rust.

Re: Inside a fast CSS engine

#46

Post by sanxiyn »

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?

First, Stylo has sequential mode. Choice of sequential and parallel is entirely modular. It should be easy to use sequential when you are on single core.

Stylo actually achieves nearly linear speedup if you just measure styling. It's really impressive.

Re: Inside a fast CSS engine

#47

Post by moosingin3space »

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…

Do you have a similar concern for all multithreaded programs?

Re: Inside a fast CSS engine

#48

Post by vvanders »

pcwalton wrote: post #39
vvanders wrote: post #26

Earlier quoted context omitted.

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

Fair enough, my data was from about 4 years ago so it may be out of date. There's some embedded GPUs that have some pretty 'interesting' architectures.

I would argue though if overdraw vs z-buffer hurt your performance then you are more than 50% GPU bound :).

Re: Inside a fast CSS engine

#49

Post by floatingatoll »

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?

I think of Servo as a non-production race car, taking risks and advancing the needle of technology to new unexplored areas. When it pays off, the results are drawn back into the production model.

Re: Inside a fast CSS engine

#50

Post by pcwalton »

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?

> Is there any real life examples of achieved speedup?

Yes, most pages have significant speedups during the initial restyle especially. Wikipedia pages tend to get 3x or so improved style recalc time on typical systems with Intel quad core CPUs, for example.

Of course, styling is only one part of the whole, so your overall speedups are limited by the rest of the rendering pipeline. That's Amdahl's Law for you. But that's no reason to not parallelize at all; it just means that we have lots more work to do once this is done :)

Post reply on HN