Transitioning Firefox's rendering engine from Gecko to Servo • Hacker News Board

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

#201

Post by Manishearth » Fri, Jan 06, 2017, 12:53 AM UTC

buzzybee wrote: post #190

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…

It's more than just architecting the drawing commands and resource management. That's just the renderer.

The term "rendering engine" is misleading; in the context of browsers the rendering engine does basically all the core browser tasks. Basically, all the stuff needed to make a web page _work_ is part of the rendering engine. Stuff like history, bookmarks, URL bar, is part of the rest of the browser. See https://news.ycombinator.com/item?id=13331505

Servo's usage of Rust is all for the rest of the stuff. We do have a component, http://github.com/servo/webrender/, which handles rendering in particular. That indeed does the architecting of the draw commands and resource management on the CPU, and has a bunch of shaders handling everything else.

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

#202

Post by yazaddaruvala » Fri, Jan 06, 2017, 12:55 AM UTC

Manishearth wrote: post #188

yazaddaruvala wrote: post #186

Earlier quoted context omitted.

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.

JavaScript does not have parallelism!

Browsers implement web workers and a "system call" which lets users initialize them through JS. A different implementation/deployment environment like Node does not have web workers. Through native modules, Node can have parallelism, but this is not a part of the language and Node isn't subject to implement web workers to be considered "running JavaScript". However, regardless of this JavaScript continues to have concurrency without parallelism. It would have been more accurate for my last message to have said: "I consider the lack of parallelism in JavaScript a feature given that it continues to have concurrency by default".

Similarly, I'd argue that C does not have parallelism (just system calls ...), but C doesn't even have concurrency. As such I do not consider the lack of parallelism a feature of C.

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

#203

Post by Manishearth » Fri, Jan 06, 2017, 1:23 AM UTC

yazaddaruvala wrote: post #202

Manishearth wrote: post #188

Earlier quoted context omitted.

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.

JavaScript does not have parallelism! Browsers implement web workers and a "system call" which lets users initialize them through JS. A different implementation/deployment environment like Node does not have web workers. Through native modules, Node can have parallelism, but this is not a part of the language and Node isn't subject to implement web workers to be considered "running JavaScript". However, regardless of…

I guess. I was thinking from the POV of web browsers.

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

#204

Post by janekm » Fri, Jan 06, 2017, 1:51 AM UTC

phkahler wrote: post #122

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…

But... Firefox itself was an example of a different approach to a transition, it started as a re-implementation of a clean, simple browser when Mozilla was getting pretty stale. The same approach could have been taken here... Firefox does feel a bit long in the tooth to me these days...

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

#205

Post by akiselev » Fri, Jan 06, 2017, 2:36 AM UTC

dingaling wrote: post #172

akiselev wrote: post #149

Earlier quoted context omitted.

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…

Youngest laptop here is from 2011: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller OpenGL renderer string: Mesa DRI Intel(R) 965GM Maximum OpenGL version for that chipset is 2.0, apparently, though I can't find a way to push it beyond 1.4 on Linux I appreciate that six years old is ancient by SV standards but I would be interested to learn what proportion of Firefox users are on equally old hardwa…

Servo isn't a production ready consumer browser and it won't be for a long time because its purpose is to facilitate research into parallel browser engines. While a 2007 chipset may not be very old among the average consumer, it is probably not going to work for a developer machine that's going to be compiling a huge codebase under active development.

I don't think the software fallback has gotten much love but AFAIK it'll work fine once llvmpipe support is added to webrender2 [1]. Once that is done, rendering will work with the vast majority of laptops and desktops running Linux/MacOS/Windows. The OpenGL version supported by that chipset is over a decade old so devoting time to compatibility this early in the project would be a waste of time (and defeat the purpose since the standard predates the explosion of mobile devices).

[1] https://github.com/servo/servo/issues/13653

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

#206

Post by frik » Fri, Jan 06, 2017, 7:09 AM UTC

phkahler wrote: post #122

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…

> If you're not careful this can drag on for years with half the stuff done

Exactly. I would suggest to focus on Servo and a HTML based UI, and take some ideas from Vivaldi browser (which has an HTML5 UI). Firefox needs a "reboot", like Firefox was a leaner reboot of Mozilla Suite - but as Mozilla Suite back then, Firefox got too bloated.

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

#207

Post by frik » Fri, Jan 06, 2017, 7:17 AM UTC

blauditore wrote: post #27

Yaggo wrote: post #12

> And Firefox runs on Gecko. Which is old. Like really old. I think it's the oldest rendering engine still in wide use. Gecko may be oldest, but not with wide margin: KHTML (the origin of webkit and blink) was started in 1998, only a year after Gecko. Of course, probably not much (if any?) of the original KHTML source is still present in webkit, and because of the nature of open source development, there is blurry li…

One could argue that Trident (or EdgeHTML as partial fork) is still in wide use, and this started with IE4 in 1997.

You mean IE3. But the code dates back to Mosaic, IE1 is based on a fork of Mosaic. And you can read about it in the credits in the Info dialog of IE up to IE6 (and even all later IE and Edge contain anomalies/small glitches from Mosaic that are still present up to this day, nevertheless the code got refactored a lot and Mosaic hasn't been mentioned in IE7+.

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

#208

Post by hvidgaard » Fri, Jan 06, 2017, 7:34 AM UTC

flukus wrote: post #199

hvidgaard wrote: post #40

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.

I'm hoping it spurs a resurgence in real desktop apps, then we shouldn't have to worry about bloated javascript.

I think people forget the rather overwhelming amount of crappy bloated desktop apps we had (and still have). There isn't anything inheriently bad with JavaScript. Webapps have strong points, and weak points, and should be used where it makes sense.

But the developers developing bloated code are most visible in the last shiny thing, which happens to be web and JavaScript. Before that it was mobile apps.

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

#209

Post by bzbarsky » Fri, Jan 06, 2017, 8:04 AM UTC

mariusz79 wrote: post #153

bzbarsky wrote: post #117

Earlier quoted context omitted.

That has two problems: 1) A lot of flight tests can't be done without a large fraction of passengers on the plane. 2) It may make getting to the final end state faster (though maybe not), but it means you don't get any benefits until you make the switch. Doing things incrementally means you start seeing benefits much earlier. Classic throughput/latency tradeoff.

What's better to end up in the final end state later, or lose customers because your software is crashing and is harder to maintain because you're introducing totally new way to do stuff?

I'm not sure what sort of distinction you are trying to make here. Again, the two options are:

1) One big switch. Can probably be done faster, but has more risk that big problems won't be discovered until late in the game and has user-visible benefits until the switch happens.

2) Incremental changes. Take longer to complete, but allow for better mid-course correction and can show user-visible benefits much earlier in the process.

Which of those will lose more customers? It really depends on the market reality and at how successfully the incremental changes can be made.

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

#210

Post by ibotty » Fri, Jan 06, 2017, 9:10 AM UTC

osullivj wrote: post #68

hvidgaard wrote: post #40

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.

Js engines are really fast. The stuff they run is bad.