Is it going to use Vulkan? Sounds like a good fit for proper parallelized rendering.
UPDATE:
Ah, I see it's mentioned in the future work: https://github.com/servo/webrender/wiki#future-work
Vulkan?
This could possibly make some of the serial
steps above able to be parallelized further.
So it will be using OpenGL then?
In The web at maximum FPS: How WebRender gets rid of jankservo
webrender
Rust2016–2025
servo / webrender
webrender
A GPU-based renderer for the web
29Distinct people
40Mentions
1Explicit recommenders
3.4KGitHub stars
What to know before exploring
What it is
A GPU-based renderer for the web
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Yes! This is because web browsers use the platform text input stack Browsers are actually a great example of my favorite approach to cross-platform UI, because they sprinkle…
conradev used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:58:02 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year40 dated mentions
Observed mentions: 2016-02-25 16:39:27 UTC to 2025-10-20 14:28:31 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
WebRender
WebRender is a GPU-based 2D rendering engine written in
Rust. Firefox,
the research web browser Servo, and other GUI
frameworks draw with it. It currently uses the OpenGL API internally.
Note that the upstream home for this code is in gfx/wr folder of the
mozilla-central repository at https://hg.mozilla.org/mozilla-central. The
GitHub repository at https://github.com/servo/webrender should be considered
a downstream mirror, although it contains additional metadata (such as Github
wiki pages) that do not exist in mozilla-central.
Generally speaking, improvements to WebRender should be submitted upstream
in Gecko, but those relevant to the Servo project or those unsuitable for
upstream may be accepted here.
If you are familiar with the mozilla-central contribution workflow, filing bugs
in Bugzilla
and submitting patches there would be preferred.
Update as a Dependency
After updating shaders in WebRender, go to servo and:
Go to the servo directory and do ./mach update-cargo -p webrender
Create a pull request to servo
Use WebRender with Servo
To use a local copy of WebRender with servo, go to your servo build directory and:
Edit Cargo.toml
Add at the end of the file:
[patch."https://github.com/servo/webrender"]
"webrender" = { path = "<path>/webrender" }
"webrender_api" = { path = "<path>/webrender_api" }
where <path> is the path to your local copy of WebRender.
Build as normal
Documentation
The Wiki has a few pages describing the internals and conventions of WebRender.
Testing
Tests run using OSMesa to get consistent rendering across platforms.
Still there may be differences depending on font libraries on your system, for
example.
See this gist for
how to make the text tests useful in Fedora, for example.
Read the full README on GitHubWhat Hacker News says
12 sourcesYou should take these advices with a grain of salt because it refers to the legacy rendering pipeline used by current web browers.
There is not absolute rule stating that layout and painting must be slow while compositing is not. In fact Mozillians are currently working on a new rendering pipeline[1] based on state of the art rendering tools[2]. This new pipeline should be deployed in firefox in 2018 as a part of the ongoing Quantum project.
[1] https://github.com/servo/webrender
[2] https://m.youtube.com/watch?v=BTURkjYJ_uk
In CSS TriggersWebRender has matured a lot lately; it's even in Firefox nightlies behind an about:config preference. That said, there are still rough edges. If you see rendering slowness, feel free to file issues on http://github.com/servo/webrender.
There are no silver bullets for performance, only lots of lead bullets. I'm confident that parallelism via GPU and multicore is a large architectural win. But lots of making the Web fast involves a ton of little special case optimizations that just need to be implemented. That's how Stylo went: promising benchmarks and a mediocre user experience at the research stage turned into great benchmarks and a great user experience with production engineering work.
In Off-main-thread HTML parsing in ServoFor anyone wandering what WebRender actually is or does
https://github.com/servo/webrender/wiki
In WebRender newsletterHave you seen WebRender? It sports impressive performance, which does help on real-world applications/sites, especially on low-end HW. While its performance gains probably come from multiple sources, pushing work to GPU is afaik one of the main ones.
https://github.com/servo/webrender/wiki
Also, I'm reminded of Anandtech review of the 1st-gen rMBP:
At 2880 x 1800 most interactions are smooth but things like zooming windows or scrolling on certain web pages is clearly sub-30fps. At the higher scaled resolutions, since the GPU has to render as much as 9.2MP, even UI performance can be sluggish [...] But there are other limitations: many elements of screen drawing are still done on the CPU, and as largely serial architectures their ability to scale performance with dramatically higher resolutions is limited.
Some elements of drawing in Safar
Read the rest
i for example aren’t handled by the GPU. Quickly scrolling up and down on the AnandTech home page will peg one of the four IVB cores in the rMBP at 100%
The GPU has an easy time with its part of the process but the CPU’s workload is borderline too much for a single core to handle. Throw a more complex website at it and things get bad quickly. Facebook combines a lot of compressed images with text - every single image is decompressed on the CPU before being handed off to the GPU. Combine that with other elements that are processed on the CPU and you get a recipe for choppy scrolling.
To quantify exactly what I was seeing I measured frame rate while scrolling as quickly as possible through my Facebook news feed in Safari on the rMBP as well as my 2011 15-inch High Res MacBook Pro. While last year’s MBP delivered anywhere from 46 - 60 fps during this test, the rMBP hovered around 20 fps (18 - 24 fps was the typical range).
The good news is Mountain Lion provides some relief. At WWDC Apple mentioned the next version of Safari is ridiculously fast, but it wasn’t specific about why. It turns out that Safari leverages Core Animation in Mountain Lion and more GPU accelerated as a result. Facebook is still a challenge because of the mixture of CPU decoded images and a standard web page, but the experience is a bit better. Repeating the same test as above I measured anywhere from 20 - 30 fps while scrolling through Facebook on ML’s Safari
http://www.anandtech.com/show/6023/the-nextgen-macbook-pro-w...
I think that demonstrates clearly how GPUs are essential for todays rich UIs, especially when targeting higher resolutions. Yes, the examples here are for web, but I don't see any reason why the situation wouldn't be the same for any other stack.
GTK is the best option at the moment. Apparently QT is difficult due to it being heavily based in C++'s view of the world, which doesn't translate particularly well to Rust (notably Rust not supporting OOP in the same way). There is hope of a new rust-native GUI library (possibly in the vain of Flutter[1]) based on the work done for Servo[2], but that looks to be a way off.
[0] https://www.reddit.com/r/rust/comments/6l5c94/can_we_crowdfu...
[1] https://flutter.io/
[2] https://github.com/servo/webrender
In Rust's 2017 roadmap, six months inand webrender too. webrender is already available in nightly as experimental option while they're still working on integrating stylo.
https://github.com/servo/webrender/wiki
In The Intel Skylake-X Review: Core i9-7900X, i7-7820X and i7-7800X TestedAgreed that Mozilla's original mission has been accomplished in spades, but I wouldn't count Mozilla out of the browser race just yet.
Servo and Webrender[0] will completely shake up the browser landscape, and will allow web apps to match (maybe even surpass?) native mobile apps in terms of rendering performance. Unless Chrome, IE, and Safari can develop an answer to Servo and Webrender by the time those technologies are ready for prime time, I wouldn't be surprised to see "Best viewed in Firefox" badges start popping up everywhere.
[0]
https://github.com/servo/webrender/wiki
https://air.mozilla.org/bay-area-rust-meetup-february-2016/
In Chrome Won> only used for hardware-accelerating video decoding and such
Not true. GPU layer compositing is implemented in all modern engines. That's how the CSS 3d transforms work. That's why the translateZ(0) hack existed to speed up animations (it created a new GPU layer. Now there's an official property for this, will-change.)
WebRender (used in Servo) goes a step further — it's not just compositing, it's actually rendering the colors, gradients, borders, shadows, rounded corners and so on in OpenGL. Look at the shaders: https://github.com/servo/webrender/tree/master/webrender/res
In Servo nightly builds on Windows now availableIt seems it will happen eventually, but not at this time[0]. There are likely higher priority changes which need to be made.
[0] https://github.com/servo/webrender/issues/186
In Firefox 51.0It'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.
In Transitioning Firefox's rendering engine from Gecko to ServoServo 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.
In Transitioning Firefox's rendering engine from Gecko to Servo