Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Converted Unix Window implementation from XCB back to Xlib. #1138
After almost 2 years of poking around XCB, it is time to declare defeat and go back to good old stable Xlib.
In retrospect, there weren't really many if any advantages for us in switching from Xlib to XCB in the first place. The main advantage users of XCB are supposed to have comes from its non-blocking nature. This might make sense in certain applications, however the way SFML interacts with the X server completely counteracts this usage pattern. There is simply no performance difference between using Xlib and XCB for SFML. The second advantage users of XCB are supposed to have is "less legacy (buggy) code" in its implementation. Being a thin (autogenerated) wrapper on top of the X wire protocol, I think it is kind of obvious: If there is no implementation to speak of, there also can't be that many bugs.
We take for granted how many other things Xlib actually does for us on the side. Those things were supposed to be supported in XCB at some point as well, but considering that it is an open source project and Wayland is arriving faster than many anticipated, one can understand the lack of motivation to continue development on XCB.
Even when using XCB, SFML still has to make use of Xlib to interact with GLX since that is still the primary API that the graphics drivers expose to this day. Mixing Xlib and XCB is a nightmare as well, which is why I already reverted the event processing back to using Xlib events a while ago.
The Unix sfml-window implementation could be considered relatively stable up to 2.2. Most of the instability came in 2.3 when we switched over to XCB. This PR seeks to restore the stability of 2.2 so that we can focus our efforts on other more pressing issues and remain an attractive library for users on Unix platforms. Once Wayland support becomes ubiquitous, we can consider supporting it in parallel to Xlib.
Fixes #1089 and possibly other bugs (requires re-evaluation if this gets accepted).
That's completely normal, since XCB will be loaded (or even injected?) by some X11 stuff. It's showing up in that list due to the way LDD works.
But you can also read that information directly from the binary using
As you can see, everything is fine, no direct reference to XCB anymore. :)