Language Selection

English French German Italian Portuguese Spanish

Mozilla: Rust, WebRender, AV1

Filed under
Moz/FF
  • Splash 2018 Mid-Week Report

    I really enjoyed this talk by Felienne Hermans entitled “Explicit Direct Instruction in Programming Education”. The basic gist of the talk was that, when we teach programming, we often phrase it in terms of “exploration” and “self-expression”, but that this winds up leaving a lot of folks in the cold and may be at least partly responsible for the lack of diversity in computer science today. She argued that this is like telling kids that they should just be able to play a guitar and create awesome songs without first practicing their chords1 – it kind of sets them up to fail.

    The thing that really got me excited about this was that it seemed very connected to mentoring and open source. If you watched the Rust Conf keynote this year, you’ll remember Aaron talking about “OSS by Serendipity” – this idea that we should just expect people to come and produce PRs. This is in contrast to the “OSS by Design” that we’ve been trying to practice and preach, where there are explicit in-roads for people to get involved in the project through mentoring, as well as explicit priorities and goals (created, of course, through open processes like the roadmap and so forth). It seems to me that the things like working groups, intro bugs, quest issues, etc, are all ways for people to “practice the basics” of a project before they dive into creating major new features.

  • WebRender newsletter #29

    To introduce this week’s newsletter I’ll write about culling. Culling refers to discarding invisible content and is performed at several stages of the rendering pipeline. During frame building on the CPU we go through all primitives and discard the ones that are off-screen by computing simple rectangle intersections. As a result we avoid transferring a lot of data to the GPU and we can skip processing them as well.

    Unfortunately this isn’t enough. Web page are typically built upon layers and layers of elements stacked on top of one another. The traditional way to render web pages is to draw each element in back-to-front order, which means that for a given pixel on the screen we may have rendered many primitives. This is frustrating because there are a lot of opaque primitives that completely cover the work we did on that pixel for element beneath it, so there is a lot of shading work and memory bandwidth that goes to waste, and memory bandwidth is a very common bottleneck, even on high end hardware.

    Drawing on the same pixels multiple times is called overdraw, and overdraw is not our friend, so a lot effort goes into reducing it.
    In its early days, to mitigate overdraw WebRender divided the screen in tiles and all primitives were assigned to the tiles they covered (primitives that overlap several tiles would be split into a primitive for each tile), and when an opaque primitive covered an entire tile we could simply discard everything that was below it. This tiling approach was good at reducing overdraw with large occluders and also made the batching blended primitives easier (I’ll talk about batching in another episode). It worked quite well for axis-aligned rectangles which is the vast majority of what web pages are made of, but it was hard to split transformed primitives.

  • Into the Depths: The Technical Details Behind AV1

    Since AOMedia officially cemented the AV1 v1.0.0 specification earlier this year, we’ve seen increasing interest from the broadcasting industry. Starting with the NAB Show (National Association of Broadcasters) in Las Vegas earlier this year, and gaining momentum through IBC (International Broadcasting Convention) in Amsterdam, and more recently the NAB East Show in New York, AV1 keeps picking up steam. Each of these industry events attract over 100,000 media professionals. Mozilla attended these shows to demonstrate AV1 playback in Firefox, and showed that AV1 is well on its way to being broadly adopted in web browsers.

More in Tux Machines

Review: Alpine Linux 3.9.2

Alpine Linux is different in some important ways compared to most other distributions. It uses different libraries, it uses a different service manager (than most), it has different command line tools and a custom installer. All of this can, at first, make Alpine feel a bit unfamiliar, a bit alien. But what I found was that, after a little work had been done to get the system up and running (and after a few missteps on my part) I began to greatly appreciate the distribution. Alpine is unusually small and requires few resources. Even the larger Extended edition I was running required less than 100MB of RAM and less than a gigabyte of disk space after all my services were enabled. I also appreciated that Alpine ships with some security features, like PIE, and does not enable any services it does not need to run. I believe it is fair to say this distribution requires more work to set up. Installing Alpine is not a point-n-click experience, it's more manual and requires a bit of typing. Not as much as setting up Arch Linux, but still more work than average. Setting up services requires a little more work and, in some cases, reading too since Alpine works a little differently than mainstream Linux projects. I repeatedly found it was a good idea to refer to the project's wiki to learn which steps were different on Alpine. What I came away thinking at the end of my trial, and I probably sound old (or at least old fashioned), is Alpine Linux reminds me of what got me into running Linux in the first place, about 20 years ago. Alpine is fast, light, and transparent. It offered very few surprises and does almost nothing automatically. This results in a little more effort on our parts, but it means that Alpine does not do things unless we ask it to perform an action. It is lean, efficient and does not go around changing things or trying to guess what we want to do. These are characteristics I sometimes miss these days in the Linux ecosystem. Read more

today's howtos

Linux v5.1-rc6

It's Easter Sunday here, but I don't let little things like random major religious holidays interrupt my kernel development workflow. The occasional scuba trip? Sure. But everybody sitting around eating traditional foods? No. You have to have priorities. There's only so much memma you can eat even if your wife had to make it from scratch because nobody eats that stuff in the US. Anyway, rc6 is actually larger than I would have liked, which made me go back and look at history, and for some reason that's not all that unusual. We recently had similar rc6 bumps in both 4.18 and 5.0. So I'm not going to worry about it. I think it's just random timing of pull requests, and almost certainly at least partly due to the networking pull request in here (with just over a third of the changes being networking-related, either in drivers or core networking). Read more Also: Linux 5.1-rc6 Kernel Released In Linus Torvalds' Easter Day Message

Android Leftovers