Intel Has Been Working On A Fast 2D GPU Renderer Focused On Web Content

[carewolf]

Actually, its arch is quite different from cairo, at least. Not sure about qtpainter (I think its called).
Also, implementation matters a whole lot, and skia tends to benchmark quite well.

Okay, I don't know Cairo that well, but I know Skia and QPainter, and they have very similar structures and API. Basically HTML5 Canvas was originally just a Web API to the WebKit graphics context, and the WebKit graphics context was Apple's reimplementation of the QPainter API from KHTML, and Skia was Chromium's backend implementation of WebKit's graphics context. So it has the same serial API with multiple different compatible backends, you can get some 2-3x speed-ups on code-path not already optimized (I do this when I am bored of my normal Qt work), but that only really ever affects special cases, it all becomes special cases, you win one benchmark dramatically, but change very little in the real world or generally. To be honest they all win whatever benchmark they have last optimized for, and break even on places they all optimized for, or all didn't optimize for. Add to that that the main limitation of all these APIs derived from QPainter is the serial synchronous nature of the API. To get really good speed-up you need to batch draw calls, and the API is not designed for that. This is also why this hardware accelerated implementation can't get any better than a 2-3x speedup, the same as a SIMD optimization. The completely redesigned scene graph of QML for instance is an order of magnitude faster than OpenGL accelerated QPainter.

[liam]

Okay, I don't know Cairo that well, but I know Skia and QPainter, and they have very similar structures and API. Basically HTML5 Canvas was originally just a Web API to the WebKit graphics context, and the WebKit graphics context was Apple's reimplementation of the QPainter API from KHTML, and Skia was Chromium's backend implementation of WebKit's graphics context. So it has the same serial API with multiple different compatible backends, you can get some 2-3x speed-ups on code-path not already optimized (I do this when I am bored of my normal Qt work), but that only really ever affects special cases, it all becomes special cases, you win one benchmark dramatically, but change very little in the real world or generally. To be honest they all win whatever benchmark they have last optimized for, and break even on places they all optimized for, or all didn't optimize for. Add to that that the main limitation of all these APIs derived from QPainter is the serial synchronous nature of the API. To get really good speed-up you need to batch draw calls, and the API is not designed for that. This is also why this hardware accelerated implementation can't get any better than a 2-3x speedup, the same as a SIMD optimization. The completely redesigned scene graph of QML for instance is an order of magnitude faster than OpenGL accelerated QPainter.

These are pretty old, but it speaks to how cairo works (both stateful and stateless, and no, you don't get to choose---you get both every time).

http://robert.ocallahan.org/2011/09/graphics-api-design.html

http://www.basschouten.com/blog1.php/comparing-performance-azure-vs-cairo

So, the issue is that cairo has this really weird EXTERNAL STATEFUL->INTERNAL STATELESS->BACK AGAIN which, for something that makes tons of calls, cairo just falls down, catatonic with WTF-ery.
IIRC, when qt made a change to their rasterizer they included a torture test where cairo just fell apart.
So, there's a damn good reason gnome is, FINALLY, looking towards a future that doesn't include cairo (though I don't know what it will be, it should, at least, expose a stateless api).