Originally posted by JS987
View Post
Announcement
Collapse
No announcement yet.
Qt5's Linux Requirements Cause Problems
Collapse
X
-
When I first read the artical I was thinking the samething as you guys but it turns out he was right and I get why he is so mad about this now. I would be mad also.
The xcb opengl artical he quoted well the author of it confirmed it and it turns out that xcb doesnt support hardware accelerated graphics in opengl it does in fact fall back to xlib.
Go see for your self.
But I dont think that was the real issue from what I can tell when Qt removed that QX11Info class it wasnt just that one they removed all the Qx11Embeded stuff also and they are not planing on supplying an alternative, some third party guy is going to try but he says he needs help. Because when they did that it is going to break a whole crap load of Qt4 applications like permanently! Not good.
He talks more about it.
Google Qt in Images and half of all the qt stuff that comes up turns out to be his work. That guy even has Qt's graphics stack working in SFML2!! Who does that lol
I like this stuff of his because I am a Arch user.
I guess we were wrong
Comment
-
This article is just plain wrong
This article is just plain wrong as already discussed on Qt devnet:
Yes, you need GLX in X11 to set up accelerated GL in X windows. That is true for both binary as well as open source drivers. GLX is indeed defined in terms of libX11 APIs. libX11 and libXCB could not be used in the same application back when XCB was new.
But all major distributions have libX11 implemented as a wrapper around XCB nowadays, so this is a non-issue. Anybody using Gnome 3 or unity or running the Qt5 demos can confirm that this rant is wrong.
The claim that Qt5 dropped X11 support in all secrecy and only this alert user found out about it is rather silly too: That Qt5 will use XCB was in the first announcement of Qt5 which said that X11 support will happen via the xcb lighthouse plugin.
Basically the guy ranting is missing some functionality that got lost during the refactoring of the code. That happens from time to time. The best way to get this fixed is to file a bug report.
Comment
-
Originally posted by bwat47 View PostHere's the results on my machine (intel ironlake with sna, xorg 1.12.4, kernel 3.5, kde 4.9.1)
raster: http://i.imgur.com/Cmlv1.png
native: http://i.imgur.com/wXEiZ.png
Definitely not as big of a difference on my machine, but native does seem slightly faster here too.
Comment
-
Originally posted by bwat47 View PostIt does say the opengl backend is still there though. Once the opengl backend matures it should be superior to both raster and x11. On my intel machine there's barely any difference between raster and x11 speed-wise, and for many raster is actually faster, if you see a big difference you should probably report a bug.
Comment
-
Originally posted by bwat47 View PostIt does say the opengl backend is still there though. Once the opengl backend matures it should be superior to both raster and x11. On my intel machine there's barely any difference between raster and x11 speed-wise, and for many raster is actually faster, if you see a big difference you should probably report a bug.
Qt developers know about big difference and won't fix it.
I will have to replace all Qt applications with GTK ones if applications will depend on Qt5.
Comment
-
Originally posted by chuckula View PostFrom the comments here, it looks like the author of this rant may not even be a legitimate developer, and the issues he's having don't even appear to be real problems. Michael: In the world of "journalism" there is this thing called fact checking and verifying sources. I know you are desparate for ad revenue from any story you can think of, but remember that people won't come back to the site if all you do is post sensationalist garbage from random Internet trolls.
Comment
-
Soo apparently I am not a legitimate developer, considering I have been a kde/qt dev for as long as it's publiclt existed. Search Qt widgets for Ogre, Irrlicht, OSG, Panda3D, SFML .... And there I am, go look at the Ogre wiki and there I am. Go research Google Skia on linux and there I am. But I am not just limited to Qt I have made contributions to Gtk/Gnome and the EFL librarys. Research custom linux desktops from scratch "as in coding them" and yes some of the only info you will ever find came from me. I was a cross desktop/toolchain developer prior to Gnome3 and Kde4 de's but I left those projects because I predicted that they would make for poor performance via gaming in the future and started working on my own stuff. Because there responce was that if you the end user didnt like it then you could go somewhere else.
Now you can put all your faith in XCB but I can assure you, they dont care about you. If you have trouble your experance with them will end badly. Its been 11+ years and there project suffers from some of the poorest written incomplete documentation I have ever seen in an oss project. Hence why I am not thrilled about jumping on that wagon. If you make a polite request for better documentation there responce will be "we dont have time to write docs for noobs" how do I know because over the last several years me and several others have reguested them and the responce has allways been the same. Try it your self "please"!!! Maybe you will be the lucky "noob"
Xlib yes has its issues but it works and it has a crap ton of documentation. If your going to throw the argument out "welll ohhh you can read the src" then you have never programmed with xcb or x11.
Because my Xlib api referance manula is 3000 pages thick.
And as far as the maui-project and razor-qt. I am working with maui I "was" working on a X compatable window manager and desktop as a fall back incase nvidia takes there sweet time about deciding if wayland is a go. The razor-qt project ask me to join them long ago I rejected them do to the fact that my design was better. But I did extend the invitation for them to join my team.
As far as GLX being depreceated and EGL is the way to go, in my mind and the minds of the other 15 or so game engine devs I am working with. Its not depreceated untill that EGL alternative is fully working on the nvidia binary drivers.
And this isnt a bug because it has allready been stated that my issues isnt going to be fixed by them and to just forget about Xlib all together or fix it my self. Beside that I have several outstanding crital bug reports that are 3 years old and there not going to be fixed eather.
If you want to talk crap about me then lets do this I am game.Last edited by zester; 17 September 2012, 04:55 PM.
Comment
-
-
And this isnt a bug because it has allready been stated that my issues isnt going to be fixed by them and to just forget about Xlib all together or fix it my self. Beside that I have several outstanding crital bug reports that are 3 years old and there not going to be fixed eather.
The question is now, how does the kde (or any other de based on qt) project will handle the situation with xcb. The current problem: The qpa implementation does not guarantee for example nativeResourceForWindow("display", window->windowHandle())) what is returned. In the QXcb* implementation there are currently two possibilities: return 0 or an xlib Display -> This depends on how you compile Qt. A de could implement their own QtGuilib, to assure the xlib implementation, but that would be ridicules.
Comment
Comment