Description of problem: I am packaging window manager awesome (see bug 452427), which needs XCB support in Cairo. ATM the support is turned off (it's claimed to be beta feature). Please, consider enabling XCB, in case it's beta-nature might influence (in bad manner) only apps using XCB features of Cairo.
The XCB backend is not supported at this time. It will change the ABI of libcairo.so, so I'm reluctant to enable it. Things may change for cairo 1.10 though. Why does awesome require cairo-xcb directly? I have a hard time believing that it can't be made conditional to use xlib instead.
Thanks for reply Behdad. From what I know: """ Only window manager using asynchronous XCB library instead of the old synchronous Xlib: make awesome faster than any other window manager; """ awesome-2 was using Xlib completely, but version 3 utilizes XCB (and Xlib for some parts). I do not think there's atm any compile-time option to switch to Xlib-only. But even in Debian it's in experimental branch.
> Only window manager using asynchronous XCB library instead of the old > synchronous Xlib: make awesome faster than any other window manager; Thats just make believe, of course...
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Will not happen until xcb becomes a supported cairo backend upstream.
Well this is automagically closing awesome review request (which depends on this BZ), which I want to live on.
What has changed here that you closed this as WONTFIX? If this statement is still valid... "Will not happen until xcb becomes a supported cairo backend upstream." (Which I read as: will be done when cairo becomes a support backend upstream). ...then this bug should be open, at least as a reminder. Please explain what are your future plans with cairo backend (as you probably know this bug prevents awesome being in Fedora), thank you very much in advance. Reopening until this.
As I said before, cairo backends will be enabled in Fedora as soon as they are marked supported upstream. There are a handful of cairo experimental backends. We don't need open bugs for each of them. At least not on my list. The XCB backend upstream is unmaintained, so it's not like it's getting closer to being marked supported at this point.
Created attachment 361578 [details] cairo.spec-xcb-bcond.patch Can we at least have bcond for xcb in the meantime? :)
(In reply to comment #9) > Created an attachment (id=361578) [details] > cairo.spec-xcb-bcond.patch > > Can we at least have bcond for xcb in the meantime? :) Feel free to commit to devel.
From the external bug: > ------- From Chris Wilson 2010-03-05 10:36:51 PST ------- > It's in progress, with the goal of xcb superseding xlib and so cairo-xlib only > being used on old systems that will not install libxcb. For continued support > of cairo-xlib, there is a proxy layer [cairo-xlib-xcb] until > applications/toolkits move onto using xcb directly. > > Clone the tree, ./configure --enable-xcb, test and send patches. Since we follow upstream's lead, perhaps we'll see this feature by f14. Should this bug be re-opened to track the validation work or should a new bug be filed?
Re-opened, it seems the cario in rawhide already support xcb backend
(In reply to comment #10) > (In reply to comment #9) > > Created an attachment (id=361578) [details] [details] > > cairo.spec-xcb-bcond.patch > > > > Can we at least have bcond for xcb in the meantime? :) > > Feel free to commit to devel. Hi Behdad, Would you mind to enable xcb support for cario 1.9.8 in rawhide? Regards, Chen Lei
Perhaps this bug should be re-set to new pkg maintainer so he can decide? Adding Benjamin to Cc.
I'm reluctant to enable xcb because I know the xcb backend is incomplete and will happily crash in your face if you do something non-standard (like run on pseudo-color X servers). That said, I don't mind enabling experimental backends if I'm confident I won't get lots of bug reports no one upstream intends to fix any time soon.
Benjamin, note that enabling unsupported backends may result in breaking ABI in the future.
There are currently 'zarro boogs' against cairo xcb backend on the Free Desktop Bugzilla: http://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=xcb%20backend&product=cairo should we file some with known problems to keep things on track?
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #15) > I'm reluctant to enable xcb because I know the xcb backend is incomplete and > will happily crash in your face if you do something non-standard (like run on > pseudo-color X servers). > That said, I don't mind enabling experimental backends if I'm confident I won't > get lots of bug reports no one upstream intends to fix any time soon. Hi Benjamin, Can we use add enable-xlib-xcb for cario 1.9? Hi Micha, Can awesome build with cairo with X11-xcb functions enabled?
(In reply to comment #19) > Can we use add enable-xlib-xcb for cario 1.9? > My problems outlined in comment 15 are still in existance. Cairo-xcb is unmaintained and buggy, so I won't enable it.
(In reply to comment #19) > Hi Micha, > > Can awesome build with cairo with X11-xcb functions enabled? --enable-xlib-xcb is not enough. cmake from awesome claims: -- package 'cairo-xcb' not found
(In reply to comment #20) > My problems outlined in comment 15 are still in existance. Cairo-xcb is > unmaintained and buggy, so I won't enable it. Could you help us understand how this jives with Chris Wilson's assertion that "It's in progress, with the goal of xcb superseding xlib and so cairo-xlib only being used on old systems". (see comment #15). If you could point me to posts or tests that show it's buggy, I'd be happy to file the proper bugs at freedesktop.org so they know about it.
You are aware that I am Cairo upstream, right? Cairo has a testsuite, running it with the xcb backend lead to wrong rendering and crashes, last I tried. You can increase the amount of crashes there if you use a non-standard X server (one without render support or pseudocolor visuals). Also, everybody upstream knows that the xxcb backend is far from ready, I don't think more bug filing will help the situation. What is missing is a dedicated upstream maintainer for the xcb backend. And I don't think that will happen anytime soon as xcb is really not all that it's cracked up to be.
For the awesome/xcb fanboys here, you may want to read awesome developer's new take on X and xcb: http://julien.danjou.info/blog/2010.html#Thoughts%20and%20rambling%20on%20the%20X%20protocol
(In reply to comment #23) > What is missing is a dedicated upstream maintainer for the xcb backend. And I > don't think that will happen anytime soon as xcb is really not all that it's > cracked up to be. Also my impression. Besides, since we switched libX11 to the XCB backend, we've lost some performance for no gain. It's especially noticeable in micro-benchmarks such as x11perf, but I bet we'd see it also with Cairo rendering benchmarks. So I'm wondering: when will we switch back to the native libX11 backend? ;-)
I need the xcb-functionality in cairo for the new versions of the i3-package family.
From 0.12.0 on, cairo has xcb support enabled per default. Current rawhide has 0.12.2, so I guess we can close this as CLOSED|RAWHIDE.
(In reply to comment #27) > From 0.12.0 on, cairo has xcb support enabled per default. Current rawhide > has 0.12.2, so I guess we can close this as CLOSED|RAWHIDE. Great news. Yep, I believe we can close it now.