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?
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?
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.
(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.)
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 back to links2 at that point.
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.
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 hardware. I did try launching Servo with CPU rendering but it hung indefinitely.
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).
EDIT: to be clear, with the Servo nightlies you need to do this yourself but Firefox could bundle it eventually.
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.
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.
That's not the aim of Rust. Rust, according to its own website is:
> Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.