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'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.
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/...)
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.
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.
> 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
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.
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! :)
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.
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!
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.
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.
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].
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'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.
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.
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.
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.
Also a great read for anyone interested in long-form technical articles that try to serve a wide range of reader types.