Yeah that's a wordpress blog quickly put together outside of mozilla's official blogging infrastructure. There was no really good reason to do that, it was just laziness on our end.
Firefox + WebRender works great in Renderdoc, either capturing the D3D11 commands generated by ANGLE or forcing opengl. The D3D11 commands and shaders correlate pretty well with the GL commands emmitted by WebRender anyway. This tool is absolutely fantastic.
Bugs are usually quickly fixed once someone on the graphics team manages to reproduce them (in a renderdoc capture).
Unfortunately nobody has managed to reproduce it yet even though the issue has been in the team's radar for a while.
If you know that the result will not change over frames, blitting a cached image will always be faster than re-rendering.
It's not necessarily a need, just an improvement. That said pathfinder is fast enough already that it can deal with rendering interesting workloads every frames at 60fps, and will keep getting better at it, I think that there is room for improvement in the tiling phase.
I find some of your comments very aggressive. Yet you are lecturing people about being condescending. I honestly much prefer pcwalton's tone which I find much less condescending, interestingly.
Pointing at code can be indeed useful, but it looks to me like you are comparing apple to oranges: Rust is not at 1.0 yet, so comparing code that isn't yet production-ready with Go or whatever technology that is already mature is not all that useful.
Saying that, in it's current state, Rust is not a good choice for production code is acceptable and fairly obvious. Extrapolating to the point of saying that it is doomed seems like quite an exaggeration to me, and not respectful of the work people are putting into this project.
I do have ideas. I also have a decent knowledge about how Gecko's graphics engine works internally.
And again, the expensive operations (actual image rendering, layout computation, compositing, etc.) all happen in the platform, that is in "native" C++ code.
What it costs to to have a good scrolling experience is to write your app in a way that doesn't cause the engine to over-invalidate and compute reflows all the time. Or it costs beefier hardware, but then this is not part of the debate of web vs native.
At some point we will really need be careful when talking about "native performances". FirefoxOS is written in JS on top of Gecko which is as "native" as it can be. if an app's UI is well written, all of the computationally expensive stuff happens in gecko. A good way to see that it is not about being native it is to compare Android and FirefoxOS on the exact same phone.
"native performances" still makes sense if you are talking about building physics engines or whatever kind of heavy simulations, but not for 90% percent of the smartphone apps today.
Indeed, when comparing ubuntu's mobile os running on a galaxy nexus with firefox os running on very cheap hardware, you should expect a difference.
I would be interested in seing how ubuntu mobile runs on a 69 euro phone.