Announcement

Collapse
No announcement yet.

Qt5's Linux Requirements Cause Problems

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Btw, the performance difference was reported upstream back in May, but no Qt developer seems to be interested:

    https://bugreports.qt-project.org/br...comment-177704

    Comment


    • #62
      It is possible that Microsoft paid Nokia to screw up Linux support in Qt library.

      Comment


      • #63
        Originally posted by JS987 View Post
        It is possible that Microsoft paid Nokia to screw up Linux support in Qt library.
        Linux support in Qt hasn't been "screwed up", so no that did not happen. Too much FUD posted on this site :/

        Comment


        • #64
          Originally posted by JS987 View Post
          It is possible that Microsoft paid Nokia to screw up Linux support in Qt library.
          Yeah, just what this forum needs is more conspiracy theorists. Qt is developed in the open as open source software by various different parties and you somehow imagine that Nokia could intentionally ruin Qt to please some other company in less than a year without anyone noticing or leaking the information? Zester doesn't sound too smart either... a guy that would rather fork an entire toolkit than create an alternate QPA backend.
          Last edited by Teho; 09-16-2012, 01:25 PM.

          Comment


          • #65
            Originally posted by bwat47 View Post
            Linux support in Qt hasn't been "screwed up", so no that did not happen. Too much FUD posted on this site :/
            Qt5 is screwed up on Linux because it doesn't support native graphics system like Qt4 AFAIK, which will mean 6 times worse performance on my PC.

            Comment


            • #66
              Originally posted by JS987 View Post
              Qt5 is screwed up on Linux because it doesn't support native graphics system like Qt4 AFAIK, which will mean 6 times worse performance on my PC.
              I think the native renderer is still there. However, raster was introduced because it was supposed to be faster, even if it's purely software. So this looks more like a bug.

              Comment


              • #67
                Originally posted by RealNC View Post
                I think the native renderer is still there. However, raster was introduced because it was supposed to be faster, even if it's purely software. So this looks more like a bug.
                https://bugreports.qt-project.org/browse/QTBUG-23022
                It seems Qt5 won't support -graphicssystem

                Comment


                • #68
                  Originally posted by JS987 View Post
                  https://bugreports.qt-project.org/browse/QTBUG-23022
                  It seems Qt5 won't support -graphicssystem
                  Those patches seem to be about the build option. If Qt5 allows switching gfx systems during runtime, then good riddance to build switches.

                  Comment


                  • #69
                    Originally posted by rohcQaH View Post
                    Those patches seem to be about the build option. If Qt5 allows switching gfx systems during runtime, then good riddance to build switches.
                    http://labs.qt.nokia.com/2012/04/03/qt-5-alpha/
                    The QWidget based stack continues to work as in Qt 4.x, based on QPainter. QPainter does however support less backends than it used to. It is now limited to SW rasterization (Raster backend) for drawing to the screen, pixmaps and images, an OpenGL backend for GL surfaces and a backend for PDF generation and printing. The platform dependent backends using X11 or CoreGraphics are gone.
                    It seems only raster is supported.

                    Comment


                    • #70
                      Originally posted by JS987 View Post
                      http://labs.qt.nokia.com/2012/04/03/qt-5-alpha/

                      It seems only raster is supported.
                      It 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


                      • #71
                        Originally posted by JS987 View Post
                        Broken fonts should be black listed.
                        This is just an example of the native backend being buggy, I don't get why you are trying to blame the fonts.

                        Comment


                        • #72
                          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.
                          http://news.ycombinator.com/item?id=4526348

                          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.

                          http://qt-project.org/forums/viewthread/20363/#97978

                          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


                          • #73
                            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


                            • #74
                              Originally posted by bwat47 View Post
                              Here'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.
                              Do you mind experimenting slightly to see what factors on your system appear to be limiting performance? I've just started to play with qtperf4 and the first Ironlake runs suggest that native performance should be several times faster than raster. Your results are worth investigating further as they are hopefully missed optimisation opportunities.

                              Comment


                              • #75
                                Originally posted by bwat47 View Post
                                It 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.
                                If I'm reading that correctly the opengl backend will only be available for drawing to QGLWidget and similar, it won't be usable for rendering normal widgets.

                                Comment

                                Working...
                                X