gstreamer + cairo == awesome
For the last few days, I’ve been listening to the gstreamer devs get excited about cairo, simply because it is awesome! Well actually because over the last couple of years the drivers have developed sufficiently that the abstraction offered by cairo solves several of the problems that the gstreamer developers have had to previously hacked around. This means that they get to dump all of their multi-threaded decoding and rendering problems on us, which makes them very happy.
In return for the extra work, we promise to make it fast as well. At the base we will be [eventually] including a jit into pixman, so that we can generate optimised code at runtime for the more obscure colorspace conversions without bloating the library by compiling thousands upon thousands of pre-computed, even hand-rolled, fast paths. But pixman is not the interface we want to present to applications, so we have an abstraction layer over that which allows applications to target GPUs, DSPs or the CPU with nary a care in the word – this is cairo. From the discussions we had, it emerged that to resolve many of the locking issues and general thread-safety concerns within gstreamer, required exposing some of the support cairo uses internally to reach its own thread-safety guarantees. However, not all backends are created equal and we will also need to fixes to the underlying libraries. For X11, this means we need to switch to xcb and for GL we need a new GLX extension to permit more efficient multi-threading.
Beyond that Benjamin is pressing for an aggressive timeline, cairo-1.10 in January so that we can make the next round of stable distributions. As my current development branch has over 40k lines of changes, with much more work required, this is quite a challenging schedule. Compared to that adding the extra interfaces and fixing the inevitable bugs is a tiny amount of work!
cairo-ickle 