Live data from Hacker News

Transitioning Firefox's rendering engine from Gecko to Servo

jensimmons.com

141–150 of 219 posts

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

#141

I've seen this before: >> At some point in mid-2017, all new CSS will be built with Quantum plane parts, not Gecko. 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. If you're not careful this can drag on for years with half the stuff done one way and half the new way - especially once you reach the poi…

A good way to force this along is to have a champion for the work, and an automated burndown metric that random devs can watch and influence.

Mozilla is pretty good at the latter, cf. https://arewefastyet.com

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

#143
post #8

The submission title has been changed from "Replacing the Jet Engine While Still Flying" to "Mozilla’s project to replace Gecko with Servo" (at the time of this writing). Some of the other comments are pertaining to the "Jet Engine" title. For anybody that might be confused, like I was :)

Why is the title back again?

No one can understand what the link is about with just engine and jet as nouns in the title.

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

#144

Earlier quoted context omitted.

The story changed its title from being about Gecko and Servo to this literally in between me viewing the frontpage and clicking on the comments link. This story here is IMO should be extempt from the "original title" rule - the original title is annoyingly misleading.

Leave the title, append it with "Transitioning from Gecko to Servo".

Yup, as soon as possible. I was also looking forward to read about jet engine being replaced in mid air.

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

#145

I just wish that their UI (UX? ugh...) team was as competent as their engine team appears to be.

What is your complaint, exactly? Considering it includes support for almost total customization of the user interface by third-party code, I think they've done an excellent job with the UX.

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

#146

Earlier quoted context omitted.

It's not going to change that. No matter how efficient you make the JS engine, crappy JS will still steal all your ressouces.

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

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

#147

I didn't look at the name of the writer when I started reading it but by the way the article is written I was suspecting it was written by a woman. Stupid analogies and fluff, lots of commas... What a loss of time...

I don't know how to say this in a civil way, so I won't: Please take your sexist bullshit somewhere else if you can't behave like an adult.

Please don't feed trolls. Instead, flag egregious comments by clicking on their timestamp to go to their page, then clicking 'flag' at the top. (You need > 30 karma to see flag links.) We monitor the flags and take action based on them. In the present case, we banned the GP account.

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

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

Rust should be just as fast as C++ and C. Benchmarks are hard of course because optimizations and such. But if Rust is significantly slower, than it is a bug.

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

#149
post #71

Earlier quoted context omitted.

Servo makes incredibly good use of the GPU. Being able to do that, and iterate so fast on that work, is part of what Rust brings to the table. (I don't think they've swapped out the font renderer and image codecs yet, but there are quite a few bits and pieces they have swapped out as the Rust community delivers more pure Rust libraries.)

> Servo makes incredibly good use of the GPU. Too good, in fact: it won't run on any laptops that I own because their GPUs don't support a sufficient level of OpenGL. One great aspect of Firefox-with-Gecko is that you can throw it onto just about any machine with more than 512MB of RAM and it will provide bootstrap web access ( slow or otherwise ). That's going to be lost when everything is Servoised. I guess it's ba…

How old are your laptops?

For ease of development, webrender2 is configured to compile with the latest OpenGl 4.x features. I believe there is a way to build it to target a lower OpenGl version.

Edit: Correction, its currently targeted at OpenGl 3.2. There's an open issue for bringing it down to OpenGl 3.1 which is the version supported by integrated Sandybridge GPUs. Considering 40% of people running Intel are using Sandybridge or older, that's probably why it wont run on your laptops.

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

#150

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.

There's no plan to write a new JS engine at Mozilla, FWIW.

And they shouldn't...let's move forward... to WASM (Web Assembly)!

Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to WASM. https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly...

Post reply on HN