Mozilla Webrender: rendering any webpage at several hundred FPS
air.mozilla.org
air.mozilla.org
"We've removed painting from the bottleneck in Servo"
More info about WebRender: https://github.com/servo/webrender/wiki
If you want try it at home, you "just" need to build servo: http://github.com/servo/servo (git clone, then ./mach build -r) and run servo with webrender:
./mach run -r -- -w http://wikipedia.org
(edit: removed the bit about chrome's gpu rasterization - see pcwalton's comment below)
brew install --HEAD servo/servo/servo
and
servo -w http://wikipedia.org
Keep in mind though, servo has a long way to go.
We have a http proxy that would like to analyze html responses and rewrite parts of the page.
Is servo ready for that or should we use something like PhantomJS?
Thanks!
==> python -c import setuptools... --no-user-cfg install --prefix=/private/tmp/servo20160225-7643-fode0q/_vedir --single-version-externally-managed --record=installed.txt Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named setup tools
UPDATE:
brew update
brew uninstall --force python
brew install python
solved it.
Incidentally, I don't deserve the lion's share of the credit here. Veteran game developer Glenn Watson is really the brains behind the project—my role has mostly consisted of picking off a few scattered features and optimizations to implement.
Vulkan/Android coming anytime soon?
(I mean, "painting on the GPU" doesn't say how you use the GPU, and I've been wondering if there's anything new happening in path rendering land after seeing a video on Kilgard's work years ago)
A future extension to support SVG and glyphs on the GPU would be pretty interesting though!
BTW, are you aware of the Halide language? Might be useful for writing those CPU fallbacks.
The drawing abstraction is actually my current big hurdle, and I hadn't thought of looking at how CSS is rendered yet. So, thanks for that hint!
Mozilla is focussing on its core competency. No mobile OS, no identity built in the browser, no distractions—no, it's just about the browser and how to make it better. What this guy showed is just impressive, well done and please more of such achievements.
So creating a new language is not at all that far away from their core competency. They are also working in a space where they have a strong need for a good systems language, so the motivation is there as well.
How about Object Pascal? I think Object Pascal is a better C++ than C++. It's too bad it isn't more widely used. Here are a couple of interesting perspectives from people who have done some recent development with Object Pascal:
1. https://news.ycombinator.com/item?id=11005203 (see also https://github.com/whatwg/wattsi)
2. http://ziotom78.blogspot.com/2015/01/lfi-data-analysis-with-...
I could only find two Rust repositories on their github page, both of which are library bindings forked from other projects, so that seems to indicate some Rust usage. But then again there are more Haskell repositories than Rust repositories: https://github.com/dropbox
Their Rust stuff is closed source, not open source.
Except a non-commercial identity provider would be wonderful. The status quo of Google/Facebook providing identity is insane. They can also use this as leverage against Mozilla politically. Hell, I get pissed when I can't google login to a site nowadays. Shame Mozilla couldn't be the ones providing this. I certainly see it as important to the web. Mozilla shouldn't be just a browser maker.
I do agree about mobile OS and other things. I don't think every organization should have its own OS. There are way too many right now, if anything, and its a non-trivial project.
We've had that all along. It's called email. It's decentralized. There are already numerous free providers. There are already numerous commercial providers. You can even be your own provider, if you want. You can have multiple identities, and they can be as loosely or as tightly tied to your actual identity as you want. Many services or web site will already let you use an email address, along with a password, to authenticate. What you're asking for already exists!
The fact that the inferior legacy solution is still around lessens the pain, but it's still a tragedy that Mozilla did not succeed to establish a competitive modern solution.
I think it is merely a matter of time until email log in is no longer ubiquitous.
That's a rather narrow view of what the open Internet should be. Declaring failure with FirefoxOS and Persona was a blow for the Internet at large: it solidifies the status quo, which is growing more closed and proprietary by the day.
Resources are understandably finite and Mozilla can't do everything at once, but there is a still lot of good they can do adjacent to the strict confines of the browser.
A better browser, including a better mobile browser is much more useful than Firefox OS every could be, IMO. In fact, this is part of what makes pure OSS Android a practical environment to work in.
I am very glad that they are continuing to put a lot of effort into Firefox on mobile.
Ubuntu is still trying, so there's that, and that's great.
1: Microsoft will ensure that capable hardware (both phones and peripherals) exists so that Continuum succeeds.
2: Ubuntu will leverage the hardware so that it's usable by the 1% who actually want it. 1% of a really big number is still a big number, so it'll be viable, if only barely.
First Microsoft is going to fail. They already are. Eventually they'll stop producing hardware, but I'll just assume you mean Samsung or whatever.
The hardware is specific to what each phone provides (which changes per device), and usually the hardware vendor ships the drivers closed source integrated with the rest of the OS. In the PC land we had a neutral Microsoft that packaged drivers and distributed them since anyone might want to change their video card. That's not what happens with phones. So Ubuntu will most likely need a very specific phone just as they are currently doing and selling. Which means random people can't just try it out, since the phone they already have and like isn't compatible (let alone "dual boot.")
Now Ubuntu and their partners have stock that needs to get sold, and everything unsold is a loss. I can't install their OS on my iPhone, so there's no community support to be building this in an open and decentralized way. My galaxy won't be supported well because of driver issues, and since android is already open source enough there's no big momentum there to change things either.
Microsoft with all their resources and power can't manage to keep their marketshare and is around 1.7%. 1% of smartphones is huge -- you think Microsoft's billions of dollars and a known name couldn't do it, but Ubuntu can on their own hardware that you now have to buy?
I wouldn't hold my breath.
Currently only the quantity of phone RAM and the display resolution are hardware issues.
There's also something to be said about the advantages that default browser's get in terms of market share.
Mozilla's move to making their own OS might have come too late but the reasoning behind it was both strategically and technically sound.
Their reasons may have seemed sound technically, but the business of building a phone ecosystem on a completely new OS were well beyond their abilities.
Sure it may not have been in their wheelhouse but they certainly had reason to try.
The reason that Firefox had the impact it did was because the browser is the gateway to the Internet. Firefox came of age just as the Internet was maturing as a platform, and because of that, Mozilla was able to play an important role in influencing the semblance of openness that we do have on the Internet today.
There was a similar platform shift to mobile, and Mozilla totally missed the boat. Now, please tell me, how will a FOSS (mobile) browser help open up the greater mobile ecosystem? The OS is the gateway to mobile, not the browser, and we need a better gatekeeper.
Yes there is: https://www.ted.com/talks/barry_schwartz_on_the_paradox_of_c...
Just since this is repeated so often: Chrome is not and never has been open source software in any shape or form. Chromium is OSS, but has only a tiny fraction of Chrome's market share and AFAIK nobody really knows what the differences between those two are (outside of the obvious: Flash player, pdf reader, etc.). Btw, Firefox is still the only major browser that's OSS, neither Safari nor Edge/IE are open source.
This isn't academic nitpicking either. Mozilla had to build a PDF reader from scratch (pdf.js), it couldn't just reuse what Chrome was using to display pdfs, since it wasn't open source. However everyone can now use pdf.js for the same task.
And the analogy holds with AOSP versus the Android that is distributed with Google apps. In any case, comparing the development of Android to Chrom(ium), it is night and day in terms of openness.
You might not consider Chrome to be open-source by your personal definition of the term but that's fine hair splitting: you can submit a patch to Chromium and some weeks later millions of Chrome users are running it; you're similarly free to fork chromium and make significant changes while still pulling in code from upstream. Yes, license nerds can argue about philosophical meanings but it's far from the closed-source world of IE/Trident, Opera, etc.
> Mozilla had to build a PDF reader from scratch (pdf.js), it couldn't just reuse what Chrome was using to display pdfs, since it wasn't open source
That's a single, separate component which, as comex pointed out, was licensed from a third-party vendor and nicely illustrates that Chrome is in fact open-source: the only reason it wasn't an option is because it wasn't part of the open source Chrome codebase.
You're also leaving out a key part of the pdf.js (and Shumway for Flash) story which was people at Mozilla trying to demonstrate that you could write complex renderers inside the JavaScript environment and sharply reduce the amount of exposed C/C++ code. I suspect they would have gone with pdfium had it been available but the security improvements would still have made that decision non-trivial.
VR will be a fascinating glimpse at where we stand in this power struggle. Do I have the right to distribute software to my iPhone owning friend? No. Only Apple has that right.
A web OS would bring us back to the age of decentralized distribution we once had with PCs and boxed software sales. It would offer a check to Google and Apple's attempt to own centralized centralized control of software distribution. An escape valve for the users who Apple and Google are currently preventing from writing the software they'd like to write (like web VR).
Without an open source web OS such apps are gated by what perhaps a few hundred engineers at these two companies can imagine, implement, and push through internal politics.
---
Sent from my iPhone.
But regardless, I didn't say "Google dragged their feet" I said "Google has an incentive to drag their feet". It's the incentive that scares me. I still trust Google to some degree, but not unconditionally.
You can have accounts at various different communities and have your experience instantly personalized when you arrive, without the sites knowing anything about you or being able to track you across sites. When you are ready, you can use oAuth to build up your profiles in different communities and use them to authenticate with each other. Finally, you have full control over which of our contacts in a community can see when you join another community -- that whole thing of "Your Facebook friend Frank Smith is on Instagram as Bunnyman123". With our protocol and reference implementation, as soon as you arrive on a site you see all the friends in your communities that also used that site -- if they decided to share this -- and your social graph is instantly connected everywhere you go. When a friend joins chess.com you'll get a notification from the friend, that they joined. If they want you to know. Maybe they wanted to check it out anonymously.
Truly decentralized identity and contacts that works seamlessly across sites.
If you liked what you just read, tell me -- how can we best position it for those people who were sad to see Personas not take off?
No, that sounds terrible, sorry. Persona did one thing: authentication. I don't want to drag in a social graph along with identity auth, but YMMV.
As I read it, that's completely optional, and I think since that doesn't exist yet (right?), having that option sounds great. I'm probably naive to dream of diaspora etc. and Facebook getting along, but even just smaller sites playing nice could make this very useful.
Jallmann, I am not sure who you think will be doing the dragging. The community? The developer of the app they install on their local copy of the platform? The friend who wants you to know that they're on there? You?
The app developer benefits from this feature for free, just by integrating with the platform's decentralized identity system. The app or community host can turn it off, or simply not implement it (eg ignore your social graph). The friend could simply not grant you the permission to see them. Or you could sign up and see your friends (who wanted you to see them) but not let your friends see you. Finally, you could turn even the social experience off and see the containing site as if you have no friends. So it's totally optional. But there are so many stakeholders in a decentralized system that ehen you said "I don't want to drag my friends" they have a choice too.
An extraneous social overlay simply isn't on my list of desirable properties for an auth system (aside from WoT type mechanisms, which is clearly not the sell here). I'm thinking SSL client certs, you're thinking Facebook Connect. Different strokes.
Anyway talking about your social login system is getting quite off topic.
Can you elaborate on what "positioning" means? I kind of read it as how it's explained or "sold", but I'm not sure. And I really like all I read here, and though I'm not sure I could helpfully answer it I would love to at least understand the question fully :)
People obviously do great work with Chrome's dev tools, though, so I'm pretty sure it's just my familiary with FF and my lack of familiarity with Chrome.
I find it more troubling seeing them continually locking down the ability to customize the browser to my liking, and instead chase Chrome's design language.
Never mind that Mozilla, like much of FOSS as of late, have been conducting all kind of "social consciousness"(or should i say "social justice"?) projects that has crap all to do with writing good code.
Projects that end up being a time and money sink for already small (compared to the various corporate entities they are competing with) orgs.
If i was the conspiratorial kind i would wonder if they had been infiltrated. But more likely they are being "infected" by a "victim" culture that has been brewing in on college campuses for some time.
Sean Griffin, on Diesel, a safe and extensible ORM [2]
Alan Jeffery, on Parsell, a streaming parser written for WebAssembly [3]
[1]: http://www.meetup.com/Rust-Bay-Area/events/219697075/
[2]: http://diesel.rs
Besides that: Thanks for these meetups and the video footage of it :)
Why can't it swap execution contexts, aka stacks? In other words, use coroutines and simply yield between chunks instead.
Wouldn't that be more efficient and simpler? Is there some aspect in Rust that makes coroutines less desirable than (manually) saving and restoring state?
Is "Servo" their "next" browser? What does the mozilla ecosystem look like? Will this technology get folded in to firefox?
This is really cool but there's a tonne of stuff here that I've never heard of.
Can anyone explain it like I'm five? How does this fit into the big picture?
To capitalise on this, and to give Rust a ‘halo’ project that uncovers potential issues early, Mozilla kicked off a project called Servo to research the ways that Rust could be used to produce a browser rendering engine. This has let them explore technologies like multicore rendering of a single page without dealing with the practical considerations (tried to find a nice way of putting it ) that Gecko has scattered throughout its codebase.
After Mozilla had made some progress Samsung became interested and started contributing a reasonable amount of code. I’m not sure if this is still happening, but you can see their interest given their prediliction for 8-core mobile CPUs.
Mozilla currently have no plans to replace Gecko with Servo outright, but they are folding Servo components back into Gecko when they’re portable and have obvious benefits. Gecko’s build chain can now handle Rust and I believe the URL parser is a port of Servo code (though I’m not sure it has landed yet). I think I recall a Mozilla engineer saying that Servo had progressed beyond a research project now, and it is pretty good at rendering reasonably complex sites, but they’ve still got a long way to go before it could be a drop-in replacement for Gecko.
Rust and Servo were basically announced to the world at the same time, as "the Servo project." It was really important that we build Servo at the same time as Rust, to make sure that the language was actually useful at building a real practical thing. The experience of building Servo helped Rust's development immeasurably. Furthermore, it also helped Rust be built in Rust itself. There's a danger when you build a boot strapped compiler: you might make a language that's great for making compilers, but not much else. Servo made sure that wasn't true.
https://bugzilla.mozilla.org/show_bug.cgi?id=1135640 is the overall tracking bug for moving Rust stuff into Firefox. Firefox 45 on Mac and Linux will contain a teeny bit of Rust, and just got turned on for Windows a few days ago. It's an MP4 metadata parser. The URL parser has a patch, but it hasn't landed yet.
That said, we do take their needs into account rather highly, just like any project with a large upstream user.
Just like we wouldn't want Rust to be useful for only compilers, "only compilers and web rendering engines" isn't much better.
The most notable example is the proposal variously known as "virtual structs" or "inheritance", which had a brief prototype implementation in Rust (circa 2013) solely to support Servo's needs (specifically regarding representing the DOM), but which met a wall of opposition from the community. Such a feature is still likely to appear sometime in the future (after all, if Servo needs it, then it's likely that others do too), but the Rust developers are taking their time to explore solutions that integrate the most cleanly with the rest of the language.
I'm not sure, as I'm on the Rust team, and not Servo; maybe someone who works on Servo directly knows better than I what plans are here.
What follows is speculation on my part. I am not a Mozilla employee.
Mozilla might, in about five years, offer a new product for desktops which features Servo, SpiderMonkey (the JS engine currently used in Firefox), and an as-of-yet undefined chrome (the UI bits around the rendered page). It may be a mobile product instead, or a product for a different type of hardware, although the current thinking seems to be to target it for desktops.
Whatever that product is, it may still be called Firefox or a derivation of that brand (as Firefox OS was), although it might have a completely new name (it worked for Microsoft Edge, after all).
(Updated for clarity.)
> Mozilla might, in about five years,
So. There's a programming language called Rust[1] which Mozilla pushed for and developed (it's now developed by a larger community, though Mozilla is still involved). Among other things, it guarantees freedom from memory safety issues and data races. Both are important here.
Freedom from memory safety issues gets rid of a whole class of security bugs (common in browsers) in one fell swoop. Lack of data races lets one write concurrent code without worrying; without needing to program defensively everywhere. "Fearless Concurrency" is what we call this colloquially, after a blog post with the same name[2].
Fearless Concurrency lets us try ambitious things like making layout parallel. Layout in browsers is the step that takes all the nodes on the page with their hierarchy (the DOM) and computed CSS style, and figures out what goes where. All browsers currently do this in a single threaded way.
Servo[3] is a research project by Mozilla. It's a browser engine[4] which does layout (amongst other things) in parallel. It's written in Rust to make this possible (and to avoid security bugs due to memory safety issues). Webrender is a (succesful!) sub-experiment to see if we can be more like game engines and do as much on the GPU as possible.
Here are a bunch of (non mutually exclusive) ways it can go from here:
- Bits and pieces of Servo's code get uplifted into Firefox/Gecko (Gecko is the browser engine behind Firefox). This is already happening[5] (integrating webrender into Firefox is something being discussed, too). This means that Firefox can get some wins without having to wait for Servo to be completed.
- Servo gets its own UI and is shipped as a new browser. A promising UI being worked on is browser.html[6].
- Servo becomes an embedding thingy to be used like a webview.
- Servo replaces Gecko for Firefox for Android: Whilst replacing Gecko in Firefox Desktop is rather hard (the two are tightly intertwined), this is less of a problem in the Android app. It's possible that Servo would have its own app that's either released under a new name or branded as the new Firefox for Android.
- Servo replaces Gecko within Firefox: Hard (not impossible). Probably won't happen.
[1]: http://rust-lang.org
[2]: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...
[3]: http://servo.org
[4]: This is not the same thing as a browser. A browser engine handles the displaying and interaction of a given webpage, but doesn't bother itself with concerns like a URL bar, bookmarks, history, a proper UI, etc.
I am in my peer group the last Firefox guy standing, but not for much longer, I fear.
There's been one proof of concept basic chrome [1] and it wouldn't be THAT difficult to build a more robust one but I'd be much more interested in seeing it running in Electron so you could run Atom or VS Code since the domains are much more limited and rendering perf is a fairly significant limiting factor in those apps.
[1] https://github.com/glennw/servo-shell
P.S. I've never had perf issues with Firefox like you're talking about. You might want to try cleaning out your profile and if it's not that, you might have addons doing something screwy.
Could you expand on "form input fields are rudimentary"? (I know they are, I'm wondering what part of this you're referring to). Is it the styling, lack of selection support, lack of HTML5 input fields, bugs, or something else? (I might be looking into improving these later)
The "go back" crash is something that can be fixed easily; I think we know why it happens but haven't fixed it yet (I forgot the reason though).
All of the above except the lack of HTML5 fields. :) I don't mean to be negative, just to give reasons it's not as simple as "just slap chrome on it". I really should start contributing.
Thanks for the feedback.
I don't understand what's up either, but I have it both on my Windows work machine with a 4+4 core desktop CPU and 32GB RAM and my Macbook with 16GB. After a couple of hours, I can type in a text-field and see the text lagging. On a 2.4Ghz machine.
I do have lots of tabs open, but since they only load on activation I doubt that's the reason. Maybe it's the Web Telegram app. It's totally frustrating that I am not even able to find the culprit if there's one since not even the dev tools have something like `ps -aux` to show what the tabs are consuming.
Granted, it's gotten better with v.45, but still I just hope something useful comes out of Servo, and soon.
Among my extensions are Classic Theme Restorer, Cookie Controller, FireGestures, RefControl, Status-4-Evar, Tab Mix Plus, Tree Style Tab, uBlock Origin, FoxyProxy amongst several others - this isn't a lightweight installation.
Chrome isn't competitive with Firefox + Tree Style Tabs, so there's little risk of me switching any time soon.
I was curious & ran a couple of tests on this 2010 Mac Book Air. Normal launch time according to about:healthreport is 2.8 seconds and testing with something like `open -a Firefox https://www.google.com` when Firefox was not already running takes 4-5 seconds to finish rendering. When it is already running, it's under a second from start to finish.
If that doesn't help, please file a bug. Getting to optimum performance with diverse hardware configurations is a slog, unfortunately, and any and all performance/hardware data is a great help :)
On mobile, where discrete graphics are a rarity and power is a scarce resource, it makes sense to offload as much work onto the GPU as possible. Light it up, do the work as quickly as possible, then go back to sleep.
However I started wondering about what can be done for high-end desktops. I just bought an i7-6700K, and of course it's paired with a very powerful discrete GPU.
So as I understand it, effectively this means about 1/3 of that 6700K is just dark all the time. If there's any GPU work to be done it will all be offloaded to the PCIe bus, not the onboard graphics.
How can we make use of that silicon in scenarios like that? Is there any advantages an onboard GPU has that can be leveraged over a discrete GPU? (Apart from power efficiency; which in my opinion is a non-issue when thinking about PCs with 800W+ power supplies.)
---
P.S: Of course all this would be moot if I had just bought the 5820K. Live and learn.
Well, in theory you could run them simultaneously. Use one of them for compute and one of them for display. Of course, this may well be quite a stretch in practice; GPU compute in any consumer software is completely nonexistent, to a first approximation. But it's worth thinking about, as there has been a steady stream of research coming out for years about various useful things that you can do with GPU compute.
My electricity bill isn't a non-issue ;-) Also power efficiency is good from an ecological standpoint.
Seriously. It's 10 minutes of work, at the outside. Normalize the audio to an average of -3 dB so that people can actually understand what's being said without having to jack up their volumes beyond all reason, and then write it back down for the next thing that they have to listen to or get the ears blasted by the next notification sound that comes along.
There's just no excuse for it.
What I am talking about is raising the volume of the quiet parts, not making all the parts of the track louder. I would listen at normal volume but be able to hear at a sane volume throughout the track. I think this can be achieved offline with the compand effect on sox.
Another listening experience improvement could be to compare the relative volume of noise outside (using the mic) with the volume of the music being played and slightly adjust the volume to keep it above the background noise.
In conclusion, it is necessary to consider the fact that listening on the phone and car happens in noisy environments and quiet passages are almost drowned if the user doesn't compensate. Why force the user with mess with the volume every few minutes when it can be achieved automatically?
Maybe a brave developer will champion this idea and release a music player or even better, an app to normalize over the whole OS so we could benefit from it while using other apps like YouTube.
I know many people want such a thing, though I wouldn't touch it myself (I like my music to have some dynamic range). But just FYI, there already exist music players that have compression plugins like rockbox and vlc, you might want to check them out.
Nonetheless, I imagine we're going to see more projects like this coming out. It's going to be great to see what people can do when they can effectively use CSS to push high framerates. It's awesome that we'll be able to easily achieve 60+ FPS animation in the browser with ease.
Here's my bookmarklet (doesn't work on embedded videos in iframes, I assume because of same-origin-policy)
javascript:void%20function(){document.querySelector(%22video%22).playbackRate=parseFloat(prompt(%22Set%20the%20playback%20rate%22))}();
When there's the bandwidth to serve it, air often fails to load fast enough for 1x.
It does. But the server is not responding fast enough for me. Both on my home ISP nor the one on my phone. So my assumption is that they have either not enough bandwidth or bad peering with my country.
They could mirror it to youtube and keep their own thing as a backup. If anything I trust content on youtube to survive the times better than Mozilla's own service. There have been too many videos going offline because the were on tiny services.
I don't there have been to many videos going offline which I embeded on my own website because YouTube took them down for various reasons.
And my MySpace content is gone, the content from 2004 in my blog is still served without problems. Example: http://jeenaparadies.net/weblog/2004/apr/ersteintrag
Tessellation shaders could get around the vertex shader limitation on weird clips
Would vulkan/dx12 reduce much given the AZDO style techniques used?
Having the GPU do work queueing might be cool as well--have it deal with the AABB tree
Very cool stuff
Indeed! It's issue #61, filed in October 2015 :) https://github.com/servo/webrender/issues/61
What would be limitation for html/css mobile app at that time compare to best of native app?
Supposedly, the authors can dynamically update the GUI/js code base on the client without going through the app store update process too.
I will love a way to have a fast html-rendered for app development, currently look like the only game is http://sciter.com
Bravo
Let's see if I can get even more excited, Would it be possible to render SVG in the same fashion ? I guess SVG can be considered a scene graph as well, maybe even more than CSS is.
If you think well, it is actually making sense, at least for the CSS part.
If you think hard it actually makes sense, at least for the CSS part.
Otherwise it reads as if in your brain you're saying "well, it is actually making sense," but then you'd need a consequence for the if.
./mach run --android -- -w https://news.ycombinator.com/
Does a transcript (and perhaps slides) of this video exist? I avoid streaming on this particular connection.
Interestingly, the same benchmarks seem pretty fast on mac chrome for me, so I wonder if I'm missing something about how effective the new technique is?
Apologies—the WebRender work has been moving fast and things are a bit disorganized.
But it would probably be possible to get the toolkit to render the control to a texture or something and move on.
EDIT: Realizing you are Patrick himself, of course you know this...
I know much less about this aspect, but I also understand, vaguely, that there are battery savings here as well? When you can get things done quickly, you can idle the CPU again, saving power. I believe that's the thrust of it.
(It also moves computation off the CPU, so the CPU can be used for better things)
You wouldn't (and the demo shows 60 fps), the point's rendering absolutely definitely most certainly isn't a bottleneck anymore, which gives more time for
> other background tasks
or other foreground tasks like the page itself (and the ability to increase its complexity since you don't need to budget for rendering anymore), or just letting the CPU go to sleep (could help whatever browser ends up with servo tech finally compete with Safari when it comes to energy consumption).
It also gets you in a good place for VR (2 displays and 90Hz minimum IIRC from a Carmack note?) or for ever-larger displays (though that ties into the complexity thing, displays also get finer and denser on mobiles)
> Unless FPS is a multiple of your monitor's refresh rate, (i.e. vsync) it won't look good.
Well you could do that with several hundred FPS anyway, 300FPS is a multiple of 60Hz, so's 1540FPS for 140Hz.
For instance, the JavaFX UI toolkit is heavily multi-threaded and uses a dialect of CSS 2, it has support for blurs, box shadows etc. The app thread renders the scene graph to some sort of intermediate form (never looked at what, but I think it's similar to the WebRender form, i.e. a series of styled absolutely positioned boxes and text regions), then a render thread translates that into Direct3D or OpenGL calls. The render thread may itself use subthreads that handle rasterisation.
You can read about it here:
http://docs.oracle.com/javafx/2/architecture/jfxpub-architec...
A link to the shader source would be great!