[arch-dev-public] cairo xcb backend
Today Cairo 1.10.0 was flagged, so it's time to update soon again. I don't know when I will introduce the new package, as I'm still working on passing the test suite included in it. Some of the tests fail here, some even crash. One thing that will definitely change is the included xcb backend. At this moment we include --enable-xcb, which is an unsupported and experimental feature. The XCB backend hasn't seen recent development, causing weird rendering bugs and sometimes even crashes. I would suggest to ship cairo 1.10.0 without the XCB backend. This means that any package that depends on the XCB backend (awesome mainly) will no longer work with our cairo package. To justify this decision, I would like to point out a comment in the Redhat bugtracker: https://bugzilla.redhat.com/show_bug.cgi?id=465759#c23
On 9/8/10, Jan de Groot <jan@jgc.homeip.net> wrote:
Today Cairo 1.10.0 was flagged, so it's time to update soon again.
I don't know when I will introduce the new package, as I'm still working on passing the test suite included in it. Some of the tests fail here, some even crash. One thing that will definitely change is the included xcb backend. At this moment we include --enable-xcb, which is an unsupported and experimental feature. The XCB backend hasn't seen recent development, causing weird rendering bugs and sometimes even crashes.
I would suggest to ship cairo 1.10.0 without the XCB backend. This means that any package that depends on the XCB backend (awesome mainly) will no longer work with our cairo package. To justify this decision, I would like to point out a comment in the Redhat bugtracker:
Fair enough, if enabling the xcb backend slows things down, especially if it is unmaintained so not likely to improve soon, we should remove it. It's a shame that awesome has to go but I'm sure the people using awesome know how to handle building from AUR/ABS and create a xcb-enabled cairo for it. Ronald
On Wed, 2010-09-08 at 16:10 +0200, Ronald van Haren wrote:
Fair enough, if enabling the xcb backend slows things down, especially if it is unmaintained so not likely to improve soon, we should remove it. It's a shame that awesome has to go but I'm sure the people using awesome know how to handle building from AUR/ABS and create a xcb-enabled cairo for it.
If it was just an optional backend, I would leave it enabled. But the fact is that the XCB backend replaces the Xlib version, resulting in visual bugs and crashes. I'm not concerned about performance here. We have a bugreport for Seamonkey that crashes with weird BadMatch errors when compiled against system cairo. Users blame me for fucking up the seamonkey package by compiling against system cairo, but in fact, the problem is most likely caused by using the XCB backend instead of the regular Xlib backend. Note that any bugreport about Seamonkey could also be valid for Firefox and Thunderbird.
On 9/8/10, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2010-09-08 at 16:10 +0200, Ronald van Haren wrote:
Fair enough, if enabling the xcb backend slows things down, especially if it is unmaintained so not likely to improve soon, we should remove it. It's a shame that awesome has to go but I'm sure the people using awesome know how to handle building from AUR/ABS and create a xcb-enabled cairo for it.
If it was just an optional backend, I would leave it enabled. But the fact is that the XCB backend replaces the Xlib version, resulting in visual bugs and crashes. I'm not concerned about performance here. We have a bugreport for Seamonkey that crashes with weird BadMatch errors when compiled against system cairo. Users blame me for fucking up the seamonkey package by compiling against system cairo, but in fact, the problem is most likely caused by using the XCB backend instead of the regular Xlib backend. Note that any bugreport about Seamonkey could also be valid for Firefox and Thunderbird.
okay, seems like the way to go. Let me know when you move it into extra so I can remove awesome from community (or do it yourself if you have community repo access). Maybe a short frontpage or forum post to notify the change too? Ronald
participants (2)
-
Jan de Groot
-
Ronald van Haren