I find this article very confusing. According to the second diagram, they get 60 fps, but it's still off by 2, which is not good, and rasterization takes almost a full frame, which I find hard to believe. In the next paragraph they say that rasterization only takes 10-20% of a frame. They say it was a data-driven decision, but I don't see any data supporting it. Even the graphs in the "Benchmarks" section use relative percentages, which tells me very little.

They should have used only ms/ns for every timing/graph, not FPS or relative percentages of whatever that was.

Bit sarcastic but did web browsers developers just discover how it's been done in real-time graphics applications (eg. games) for decades...?

Yes :) all current browser engines have their roots in the Nineties (webkit is also based on KHTML). This is what WebRender (part of Servo) to be added to Firefox Quantum / Gecko will change.

I remember hearing that Firefox’s recent engineering work is actually directly based off game development.

It's not mentioned in the blog post, but OMTP is expected to ship for Windows in Firefox 58 (January) and Mac and Linux in Firefox 59 (March).

Windows bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1403935

I've been using Nightly (currently v.59) for several months on Linux, and I can't honestly remember the last time it crashed.

I don't quite understand the graphs. If all we did was move rasterization to a separate thread, how does it take any time in the frame at all? Are we measuring instead the cost of synchronization/contention? If we measured rasterization time exactly the same, wouldn't the absolute quantities be relatively similar since we aren't changing the rasterization algorithm itself?

One interesting thing I realized reading this is that I've never bothered looking at Direct2D, having used Direct3D forever.

Is advanced layers still DirectX only?