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

Transitioning Firefox's rendering engine from Gecko to Servo

jensimmons.com

Post reply on HN
Print view View original

181–190 of 219 posts

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#181

Post by Manishearth »

Touche wrote: post #140

> Going forward, it will be much easier and more enjoyable to implement new CSS properties. Which makes it easier for folks in the open source community to contribute. Which makes new things come out faster. I had never really thought of Servo in these terms before, but it makes a lot of sense. Mozilla, being a nonprofit, can't compete with Google / Apple / Microsoft doing things their way . They inherently have a gr…

Note that most of the recent Rust "marketing" articles have nothing to do with Mozilla and weren't a coordinated effort (https://news.ycombinator.com/item?id=13325196), it just sort of happened.

This specific article is by Mozilla from the Developer Relations team, so you might call it marketing, but there hasn't been such an article from Mozilla for quite a while now.

But yeah, I agree, Rust will make it easier to contribute to Firefox IMO. We have a lot of contributors on Servo.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#183

Post by Manishearth »

ComputerGuru wrote: post #54
osullivj wrote: post #7

Earlier quoted context omitted.

Looking forward to it too; this is a big deal because it will put a Rust implementation on many millions of desktops. I'm totally fed up with CPU and memory hogging browser bloat on my laptop. My dev env runs so much better when I kill all Chrome processes. I know that the article is only talking about the render engine, and not JavaScript, which I suspect is the main browser bloat culprit , but I'm still hopeful. Br…

Rust is neither faster nor more efficient than C++.... its benefits lie elsewhere.

A big part of Rust is that it lets you very easily parallelize things, even in super complicated situations, because it keeps it safe. The corresponding task might certainly be possible in C++, but not necessarily always maintainable. Doing Servo's parallel styling or layout in C++ would be very hard.

So it doesn't produce more efficient machine code, but it does open up new opportunities for optimization at a higher level.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#184

Post by Manishearth »

ishitatsuyuki wrote: post #25

They are still using many unsafe blocks and there was an use-after-free before :P

The use after free basically had to do with spidermonkey, which has a GC, and is not 100% safe to use in Servo (we try to make it safe).

The quantum projects don't involve moving Servo's DOM into Firefox (they do involve implementing lessons learned from Servo's DOM, but not the DOM itself), so this isn't an issue.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#185

Post by Manishearth »

mozumder wrote: post #56

Wouldn't it be more appropriate to have written rust in a GPU language like OpenGL or OpenCL, since the aim here was to replace the display engine? Curious as to why use a CPU language for the display engine rewrite? It seems to be wasting the GPU all modern systems now contain.. Also, is it fully replacing the display engine, including the font renderer and image codecs?

Servo is not a "display engine". The term is "rendering engine", but that's an inaccurate bit of terminology, most of what a rendering engine does doesn't actually deal with rendering. A better term is "browser engine".

Parsing, styling, the DOM, running JS, handling networking, computing layout are all things that a browser engine does that don't involve rendering. Many of these can't be done on the GPU, and for others the GPU brings no additional benefit because it's not the kind of load the GPU can magically parallelize.

Servo's rendering stack does make extensive use of the GPU. https://github.com/servo/webrender/ (talk by patrick in https://air.mozilla.org/bay-area-rust-meetup-february-2016/) There's also work on glyph rasterization on the GPU going on right now.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#186

Post by yazaddaruvala »

Cshelton wrote: post #146
osullivj wrote: post #68

Earlier quoted context omitted.

Yes. However, a crappy, leaky, JS engine running crappy JS code will steal all resources even quicker. I hope a JS engine built with Rust smart ptrs will be less leaky than one built in C/C++. In my experience, hand rolled memory pooling systems can be very leaky.

I wonder if it would be possible to write a JS engine in Rust that would essentially make multi-threading JS possible... Use Rust's concurrency safety to pass resources around threads running JS. Doing this without making any changes to JS. Of course Node would then also be obsolete...

I consider the lack of parallelism[0] in JavaScript as a feature of JavaScript.

[0] Note: parallelism is not the same as concurrency.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#187

Post by gsnedders »

kibwen wrote: post #166
gsnedders wrote: post #96

Earlier quoted context omitted.

While writing a browser in Rust might not be, per-se, particularly experimental anymore, nobody has written a browser engine from scratch since KHTML in 1998, and with the growth in complexity of the web since then it's unclear whether one can write a new browser engine from scratch without spending years reverse-engineering the competition—we've come a long way in the past decade in better defining many historically…

> it's unclear whether one can write a new browser engine from scratch without spending years reverse-engineering the competition That's to Mozilla's advantage, given that no company in the world has more historical experience reverse-engineering browsers. :P > how does that interact with things like the Grid Module? Servo devs have definitely identified places in the HTML spec which, entirely by accident, require se…

> That's to Mozilla's advantage, given that no company in the world has more historical experience reverse-engineering browsers. :P

I'd claim Opera (or rather the consortium that now own the Opera browser) have the most experience of reverse-engineering browsers, given Firefox's market-share solved a lot of the site-compat issues a long time before Opera gained market-share (oh, wait, it never did significantly after the rise of IE). On the other hand, almost nobody from the old Presto team is still at Opera, so… ;P

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#188

Post by Manishearth »

yazaddaruvala wrote: post #186
Cshelton wrote: post #146

Earlier quoted context omitted.

I wonder if it would be possible to write a JS engine in Rust that would essentially make multi-threading JS possible... Use Rust's concurrency safety to pass resources around threads running JS. Doing this without making any changes to JS. Of course Node would then also be obsolete...

I consider the lack of parallelism[0] in JavaScript as a feature of JavaScript. [0] Note: parallelism is not the same as concurrency.

JS does have proper parallelism, workers can run on separate threads and could be run on separate processors. There aren't as many primitives for dealing with cross-worker communication, but some exist and it's usable.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#189

Post by nnethercote »

beezischillin wrote: post #179

I'm so happy to read this and all I can say is I hope they succeed - the faster, the better. I used to run Firefox and loved it so much, but it started falling behind in performance so much that I had to switch out of necessity. I haven't really seen it improve much over the years. On the contrary, Safari, while it always felt a bit slower than Chrome, is feeling faster and faster with each update. Working at a compa…

> I have animations that run at a smooth 60fps in Chrome and Safari effortlessly, quite often producing 1-2 FPS in Firefox.

Can you give an example? I'm sure Mozilla's animation people would love to hear about this.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#190

Post by buzzybee »

mozumder wrote: post #56

Wouldn't it be more appropriate to have written rust in a GPU language like OpenGL or OpenCL, since the aim here was to replace the display engine? Curious as to why use a CPU language for the display engine rewrite? It seems to be wasting the GPU all modern systems now contain.. Also, is it fully replacing the display engine, including the font renderer and image codecs?

This is a misunderstanding of what a rendering engine does. It operates on at least two layers:

1. On the CPU, architecting the drawing commands and resource management for the GPU

2. GPU programs (in the form of API calls, shaders, output buffers, etc.)

Generally speaking, part 1 is not the resource-intensive part unless you also have to run an intensive algorithm on the CPU. If you see the renderer as a synthesizer unit, the CPU is the number of user parameters you have - the number of knobs and switches and sliders and patch points. You would typically only have a few knobs to turn, if you were writing a custom renderer for your application. But a complex, general-purpose renderer like that of the HTML DOM is more like a wall of patch cables; and within that, the Servo renderer found opportunities to make "risky" optimizations that parallelize, make tighter use of memory, etc., but many of them are only reasonable to do from within Rust, because of the additional checks it can perform.

Post reply on HN