HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
servo
webrender
Rust2016–2025
servo / webrender

webrender

A GPU-based renderer for the web

29Distinct people
40Mentions
1Explicit recommenders
3.4KGitHub stars
REPOSITORY AT A GLANCE

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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM 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.

0369122016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC514
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC12012
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC725
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC505
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC303

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 GitHub

What Hacker News says

40 sources
Mathematically, what you want to do here is to calculate the area of the pixel square (or circle; however you want to approximate it) that the shape covers. In this case a linear ramp actually approximates the true value better than smoothstep does. (I had the derivation worked out at some point; I don't have it handy, unfortunately.) Of course, beauty is in the eye of the beholder, and aesthetically one might prefer smoothstep. By the way, since the article mentions ellipse distance approximations, the fastest way to approximate distance to an ellipse is to use a trick I came up with based on a paper from 1994 [1]: https://github.com/servo/webrender/blob/c4bd5b47d8f5cd684334... Unless it's changed recently, this is what Firefox uses for border radius. [1]: http://mesh.brown.edu/taubin/pdfs/Taubin-tog94.pdf
In Perfecting anti-aliasing on signed distance functions
That's something I was thinking a lot about back when I was working on Servo. Wasm + a protocol to talk to WebRender (expose display lists [0] to the wasm runtime). Some sort of "mini web", a minimal runtime that would do just enough that most web APIs could be re-implemented and shipped from the webpage directly. The DOM, the CSS parser, the layout engine, … could just be shipped as wasm modules. Kind of defeat the purpose of view-source, but nowadays, it's a lost battle already. And I didn't think too much about sandboxing, accessibility, network or whatnot. Just a fun idea… [0]: https://github.com/servo/webrender/blob/c4bd5b47d8f5cd684334...
In WASM Wayland Web (WWW)
This source code: https://github.com/servo/webrender/blob/master/wr_glyph_rast... suggests to me that the glyph rasterization (which is the CPU-limiting factor for text rendering) in WebRender (which is the new FF 93+ GPU-accelerated rendering engine) is implemented in Rust and to be run on CPU. On Linux it appears to use FreeType (which is CPU-only): https://github.com/servo/webrender/blob/master/wr_glyph_rast... Also, that approach of pre-rendering text into textures is, sadly, very common. For example, see: https://stackoverflow.com/questions/44062566/how-do-hardware...
In AvaloniaUI: Create Multi-Platform Apps with .NET
> No. I mean like WebRenderer[3], Lyon[4]. Most things should be parallelized and done on GPU/SIMD. Layout, font shaping, etc. https://www.reddit.com/r/rust/comments/vwdxim/announcing_lyo... https://www.reddit.com/r/rust/comments/vwdxim/announcing_lyo... Also neither of your examples do any text shaping on the GPU. Lyon doesn’t do text and Webrender (which depends on freetype) does regular old glyph cache built in CPU texture rendering. Neither involve GPU shaping. https://github.com/servo/webrender/blob/master/wr_glyph_rast... Still trying to understand what earth-shattering, "leverage" levering feature this brings compared to Skia. > Memory model of Rust is undefined[2]. It might be anything Rust does to accomodate C++ bindings, but I don't think they really settled on one. > I'd like to add - people have been doing large scale parallel
Read the rest
software development for years in C++, in spite of C++. Do you not see at least some level of contradiction to these statements? This is probably the more relevant explanation: https://doc.rust-lang.org/nomicon/atomics.html. "At very least, we can benefit from existing tooling and research around the C/C++ memory model." Perhaps respect your elders a bit more?
In macOS Apps in Rust
> Maybe. Gtk and its related libraries don’t cover everything Qt does And therein lies the problem. Qt is semi-open (the parent company tried to close source it[1]). If a commercial company has no interest in maintaining it, there is even less hope for other open source approaches. Best cross OS system are almost always backed by a commercial supporter. See Skia - Google, Java Swing - Oracle, Qt - QtCompany, etc. OSS offerings were always runner ups (e.g. Gtk - Gnome). > The memory model of Rust is still whatever C++ does. I get that Rust has some nice features and C++ makes it easy to fuck your self but people have been doing large scale parallel software development for years in C++. Memory model of Rust is undefined[2]. It might be anything Rust does to accomodate C++ bindings, but I don't think they really settled on one. I'd like to
Read the rest
add - people have been doing large scale parallel software development for years in C++, in spite of C++. What is a line of comment in C++ in Rust is a type system constraint. It's a difference between having a seatbelt (Rust) and holding a piece of seatbelt (C++). Rust was literally made to address C++ shortcomings when it comes to parallelism. > You mean like QtQuick/QML, skia (basically this is the effective underpinning of electron and flutter) or Dear Imgui, etc. There are a handful of widely used GPU based GUI libraries. The above examples are all C++. No. I mean like WebRenderer[3], Lyon[4]. Most things should be parallelized and done on GPU/SIMD. Layout, font shaping, etc. [1]https://news.ycombinator.com/item?id=25656932 [2]https://doc.rust-lang.org/reference/memory-model.html [3]https://github.com/servo/webrender [4]https://docs.rs/lyon/latest/lyon/
In macOS Apps in Rust
This is in the context of rust. > it adds a line to a `go.sum` while with a hash of the code at the version specified Cargo.lock also contains a checksum > You can distribute your code without a copy of the dependency Also true in rust, and the default way of using rust/cargo. > If the hashes are different, an error is thrown. Also true in rust. For an example of what this looks like: https://github.com/servo/webrender/blob/54b725be37f13b166946... You haven't described anything different between go and rust in your comment since every feature you've pointed out applies equally to both.
In Rust: Does the published crate match the upstream source?
conradev·Aug 27, 2021Recommendation phrase
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 platform-native widgets throughout the canvas that they render, controlled by a platform-agnostic programming language. Which reminds me that people were trying to use webrender[1] to build native apps in Rust. [1] https://github.com/servo/webrender
In Iced: A cross-platform GUI library for Rust, inspired by Elm
Firefox integrates into some platforms better than others. There are some proposed changes to fix this, but they aren't quick fixes. >Write bindings to all relevant OS composition libraries. For Windows, we already have DirectComposition bindings, and for Linux, there are already bindings to Wayland. We need bindings for macOS Core Animation (which runs in the window server on relatively recent versions of macOS) and Android SurfaceFlinger. https://github.com/servo/webrender/issues/3115 On the Mac you can pick up performance improvements now by opting out of the OS's window scaling feature for the Firefox app. Get info for the Firefox app in the Finder and select the option to "Open in Low Resolution".
In Microsoft proves the critics right: We’re heading toward a Chrome-only Web

Showing the 15 most recent of 40 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.