WebRender is in beta | Hacker News Reader

WebRender is in beta

mozillagfx.wordpress.com

242 pointsbpierre74 comments

For anyone (like me) not familar with WebRender, here's a great writeup: https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f...

Also a great read for anyone interested in long-form technical articles that try to serve a wide range of reader types.

I'd be curious how the power usage compares between this GPU rendering and the old CPU painting / compositing rendering. I'd expect it to save power but could also see it going the other way, particularly for webpages with minimal changes from frame to frame.

At present power usage tends to be worse with WebRender, but I'm working on that with OS compositing (planeshift), and Glenn is working on that with picture caching. I expect it to be an overall energy consumption improvement over the old graphics system once this work is complete, due to reduced overdraw and better use of OS composition.

The moment you said put "great writeup" and "hacks.mozilla.org" in the same sentence, I had a feeling it would be Lin Clark. Highly recommend her articles, I've learned a ton about Firefox's internals from her.

I've just made very basic integration with node. It's rather PoC, but it works.

It can currently show a window and render moving rect from vue.js template. There's still a lot of work to be done, webrender does too little to be just drop in replacement for electron but it might be worth watching if you're interested in anything like that (lightweight cross-platform opengl-rendered gui apps developed in react/vue/angular/...)

https://github.com/cztomsik/node-webrender

This is a nice experiment ! There are a few people starting to hack around with WebRender. There are already Limn, Azul, Stylish, etc...it would be nice if we joined forces in developing one good UI framework powered by WebRender.

https://github.com/christolliday/limn

https://github.com/maps4print/azul

https://github.com/Thinkofname/stylish

Here's another:

https://github.com/antoyo/servo-gtk

Thanks for those links, azul is very interesting!

This is my first rust project, so I'm not sure if I would be any help

I also think it's better to have as much GUI part as possible in typescript, try-and-refine cycle is shorter and imagine how it could be with live/hot-reload

What I'm trying to do is something like electron but lighter, faster and memory-savvy. I think it could use azul, so thanks a lot :-)

I agree, I think Typescript is a very good pick for UI developpement, it's easy to use yet you still have types that help with maintainability. I would definitely be using something like this to develop apps :). However there are people who prefer other languages so it'd be nice if we could have a WebRender UI framework on which we could write bindings for any language, similarly to QT and GTK that have bindings for several languages.

I really like these kinds of projects—lightweight UI frameworks on top of WebRender. Fantastic to see :)

I was imagining graphene would be something like an electron replacement

the demo runs very choppy and the window is not closable here

it's not animated at all actually, there's 100ms setInterval, which mutates the state and the vue then in turn sends a new frame

https://github.com/cztomsik/node-webrender/blob/master/examp...

Does it require JavaScript, or can you interact with WebRender from something lower-level, like C++ or Rust?

Most up to date presentation on WebRender I could find:

https://www.youtube.com/watch?v=hXzLC6ArlgE

Slides:

https://github.com/MadRust/talks/blob/master/slides/meetup3_...

> Kats is standing up WebRender in Firefox for Android

I'm guessing "standing" should be "setting"? Anyway, doesn't seem to work just yet for nightly. I enabled in about:config, but get "unavailable by runtime: WebRender not ready for use on non-e10s Android". Also, "WEBRENDER_QUALIFIED: blocked by env: Has battery"

I filtered by e10s and electrolysis in about:config but couldn't find anything

Standing up here means getting into a working but unfinished state. It’s a slightly uncommon turn of phrase, but it’s legit English.

Is this the opposite of "stand down"? It seems to be.

I think its more like "to erect"; "to stand down" is more like "hold back", "disengage" or "retreat" (intransitive).

stand up (intransitive) ~= stand from a sitting or lying position

stand up <direct-object> == erect, build, appoint, enact

stand-up, upstanding (adjective) == moral, ethical

stand-up [comedian] == actually standing on ones feet

To me it's very common in the tech community. Maybe a transfer from the embedded/sysadmin/DBA side of things, from what I've seen its usage move over time.

You aren't used to hearing about "standing up" new servers?

I must have written my text poorly, that's what I intended to convey; that in my experience the term's popularity started in the embedded/sysadmin/dba communities and then spread to the wider tech communities. Sorry! :)

I hear this phrase frequently in programming. In order to get your program running, you first have to make it stand up.

Computer jargon for "set up", likely from (US?) military jargon.

https://english.stackexchange.com/questions/125681/usage-of-...

It doesn't yet work on fennec (regular Firefox for Android, which is non-e10s). Instead we're working on it for geckoview.

To add to this - this means it could be enabled in focus/klar nightlies, except they don't have an about:config page. You can build it from source, though!

It's very early days currently so you're not missing anything, but as it gets more stable I'm sure it'll be easier to try out.

I keep wondering about GeckoView vs Fennec. Surely Fennec already contains something much like GeckoView, so what will the difference be and when will (Nightly) Fennec switch?

GeckoView and Fennec share the same Gecko code, but GeckoView provides an embedding API for other apps and has some runtime differences like enabling e10s (sandboxed content process separate from the app UI). GeckoView-based features (like e10s and WebRender) will eventually be folded back into Fennec.

Me too. A bit of Googling told me that if you set the variable MOZ_WEBRENDER=1 it enables it. That worked.

That doesn't seem to work

I haven't tried these instructions, but the Android WebRender bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1453367#c13

says to download the "geckoview_example" app's APK:

https://queue.taskcluster.net/v1/task/AY-d7ns9QOGZuFj3syrsDQ...

and then remotely launch the geckoview_example app from a connected desktop machine:

  adb shell am start -n org.mozilla.geckoview_example/.GeckoViewActivity --es env0 MOZ_WEBRENDER=1

Enabled in FF Nightly 65.0a1 (2018-10-26) (64-bit) and it felt a little sluggish especially with regards to scrolling. I understand it's in beta but I guess I was expecting things to "feel" faster. Tried resizing larger sites/pages and things felt snappy but scrolling felt jumpy and off.

That said, can't wait for this to come out of beta!

I've experienced the exact same thing on latest thunderbird betas and nightlies.

Its a shame that GPU support by Mozilla products is in such abysmal state. Meanwhile Google has working hardware accelerated video decoding AND decent GPU support in Chrome.

Firefox has had hardware video decoding and GPU support for like 15 years? This is just a new graphics stack.

It doesn't on Linux (see https://bugzilla.mozilla.org/show_bug.cgi?id=1210726 and https://bugzilla.mozilla.org/show_bug.cgi?id=594876).

As the sibling comment mentions, not on Linux. Perhaps I should've been clearer, but the point still stands.

This is that "GPU support", on Linux anyway.

Hardware accelerated video decoding is barely worth it on Linux. Crashes galore. Does Chromium even enable it by default?

The problem is not writing the "GPU support", but working around the mountain of Xorg bugs that it triggers. As an example just this week, I recently ripped out OS compositing support from WebRender on X because it was simply impossible to deploy without crashing. (It will still work on X, but energy usage will be worse.)

Glad to hear work this is something that's being worked on because Firefox is still losing market share. And that's not good news for all of us.

You may put GPU support in quotation marks, but Chromium is way snappier and faster than Firefox nightlies on my Linux box, and I suspect taking advantage of the GPU is a part of the equation.

I also suspect the whole pipeline is more optimized on Chrome. Firefox has ~3x the input latency[1] and unlike Chrome, also slaughters my CPU when watching youtube videos.

Its not like Mozilla is under-resourced. I think its just a matter of priority[2].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1408699

[2] https://blog.servo.org/2018/03/09/servo-and-mixed-reality/

I'm putting "GPU support" in quotes because "GPU support" is such a broad topic that it's impossible to pin down precisely what you might mean by it. There aren't any areas I'm aware of in which Chrome uses the GPU whereas Firefox doesn't. If anything, WebRender makes it the reverse, though since Chrome uses Skia-GL it's more of a matter of which GPU features a browser uses rather than whether a browser uses the GPU (in particular, WebRender uses the Z-buffer and the early-Z functionality, which are quite an improvement).

I will say that, in my opinion, WebRender is generally better optimized for modern graphics hardware than Skia-GL as used in Chrome, due to the reduced overdraw via aggressive use of the Z-buffer and better batching.

Often times performance bugs are just that—bugs. The existence of performance bugs doesn't necessarily indicate that "the whole pipeline" in one browser is better than the other. Browsers are broadly quite comparable in terms of the script-layout-painting pipeline these days. In the case of Firefox, I'm personally confident in the IonMonkey-Stylo-WebRender trio.

You're literally talking to one of the main initial people behind the Mozilla project that uses the GPU for browser rendering more than any other browser, on the comments of a post about this stuff making its way to a release.

Webrender has a pretty large team working on it at this point.

You have no idea what you're talking about here.

> You're literally talking to one of the main initial people behind the Mozilla project that uses the GPU for browser rendering more than any other browser, on the comments of a post about this stuff making its way to a release

I don't see how this vague appeal to authority adds anything to the conversation.

> Webrender has a pretty large team working on it at this point.

I guess what you're trying to say is that Firefox and Webrender in particular is a high priority for Mozilla. I would like to believe that this is true, but take a look at what Mozilla allocates its resources to[1] - Firefox Reality, Firefox Monitor, Pocket, ethics in CS, women who tech, etc. All fine and dandy, but the problem is that time is ticking for Mozilla Firefox.

Firefox is not even at feature parity with Chrome, never mind performance parity. For instance, I filed a bug[2] on bad input latency a whole year and 7 releases ago, and its still not fixed. A devtools bug for a websocket frames inspector[3] was filed 5 years ago, and its still not fixed either.

The time it takes to fix bugs and ship all these features is inversely proportional to the dedicated manpower. By the time Firefox reaches feature/performance parity with Chrome, it will have an insignificant single-digit market share, down from ~10.5% now. And that is with the incorrect assumption that Chrome will remain static.

[1] https://blog.mozilla.org/

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1408699

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=885508

One must wonder, if Firefox might do better at being a browser, if they stopped chasing money by questionable integrations with tangential services and focused on their core competencies. It seems like hardly a week can go by without a new announcement that Mozilla has their fingers in some new also-ran company in a new market.

Chromium has long-standing unresolved issues about adding GPU acceleration for video decoding too?

https://bugs.chromium.org/p/chromium/issues/detail?id=463440

https://chromium-review.googlesource.com/c/chromium/src/+/53...

Honestly, I think it isn't worth it, as long as we're on X. X11 is not a reasonable protocol, and Xorg is not a reasonable implementation anymore. It's had a good run, but it's time to move on.

Will the situation improve with Wayland? It seems like Firefox is generally moving in the direction of natively supporting Wayland but it doesn't seem like a high priority for now.

I have some working preliminary Wayland integration for WebRender as of this week. However, there's a whole lot more than WebRender integration that needs to get done for Firefox to stand up on Wayland.

Thanks for the info. Obviously WebRender and Wayland integration are separate concerns but I was mostly curious if you had any idea if Wayland would address the issues you were running into with X11/Xorg.

Yes, Wayland is looking a lot better. The most important feature is transaction support, which is weird in Wayland but better than X, which has none at all.

I've never used smooth scrolling in any browser (Firefox, Chrome, IE) that didn't feel laggy. It's the first thing I turn off anymore.

Safari and Edge with touch scrolling are buttery smooth! If you’re talking about a smooth scrolling option imposed on a clicky mouse wheel, I’m not sure if it’s even possible it is to make that feel snappy.

Yep, Edge gets it right when you have a precision trackpad. Chrome and Firefox unfortunately do not track the motion on the trackpad nearly as well

If you're on windows, it could be a compositor bug. Does it only feel sluggish with mousewheel scrolling or does dragging the scrollbar feel bad too?

Could be this bug, for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1490991 Maybe worth chiming in if it is.

Wondering if Pathfinder made it to this release? Perhaps pcwalton could chime in?

It's in the codebase as an optional code path for fonts but not enabled. The graphics team prefers to do a staged rollout where we roll out WebRender first before enabling Pathfinder. I agree with the caution.

Happy to hear it's in the codebase. It's an exciting project!

Firefox has become crazy fast lately. Which is great! But on systems like a Surface tablet it seems to chew through battery much faster than Edge.

It seems to be pages that are actively modifying themselves. If they just sit there being static the power use isn't a problem.

Out of curiosity, is WebRender written in Rust?

Yes it is

Yeah: https://github.com/servo/webrender

https://github.com/servo/webrender/tree/master/webrender/src

For pages like Facebook and Reddit, the performance is great. But Chrome is almost double the framerate for svg animations (I measured on a Macbook).

WebRender doesn't accelerate SVG yet. That will be the second stage of the Pathfinder work. Stay tuned :)

So soon even more things won't work right due to buggy GPU drivers on linux?

Does it work on macOS atm?

Yes, I'm using it in Firefox 65.0a1 on a 15" 2017 MBP running High Sierra.

After setting gfx.webrender.all to true and restarting, check about:support and you should see "Compositing: WebRender"

Of course you may still hit bugs.

I think it's still disabled on beta for Mac laptops, but it could just be that I have an older (2014) MBP than you do.

These days I don't see many bugs. I hit a crash this week, but it was fixed within a day.

Is GPU rendering going to open up new security holes? If not, then how do we know it won't?

Can you be more specific as to which "security holes" you're thinking of? You're kind of asking to prove a negative.

Not at all. I'm asking what the current approach and what the current thinking is about this topic.

Great work on this!

"Bobby fixed a crash" - A crash relating to what? This changelog is awful, who approved this?

It's a changelog for prerelease software, the standards are a bit lower.

This isn't a changelog, this is a newsletter for folks wanting to keep up with development.

Reply on news.ycombinator.com