Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Mobile and Embedded
  4. [Solved] Qt application run on Qt5.3.0 is slower than run on Qt4.8.4
QtWS25 Last Chance

[Solved] Qt application run on Qt5.3.0 is slower than run on Qt4.8.4

Scheduled Pinned Locked Moved Mobile and Embedded
9 Posts 4 Posters 4.2k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D Offline
    D Offline
    donbychang
    wrote on last edited by
    #1

    Hello everybody
    I have tried to port Qt5.3.0 on my platform ARM freescale iMx6 recently.
    There was no any problem when building.
    However, when I run a simple Qt application with this command:

    ./qmlviewer -platform eglfs

    I found that the application was so slow to show, it took about 10 sec to show.
    But I recompiled the same Qt application with Qt4.8.4 and run with the same command,
    it only took about 2 sec.

    Not only qmlviewer application but also other my own gui applications have the same problem.
    I searched at here on the internet to see if there was the same problem and found the similar discussion:

    http://stackoverflow.com/questions/22662858/qt5-eglfs-on-embedded-linux-ti-am355x-evm-starter-kit

    But he used the TI board, I'm not sure whether the platform problem or there is another root cause.
    Therefore I start this discussion and ask for your help.
    Thank you very much and appreciate!

    1 Reply Last reply
    0
    • sierdzioS Offline
      sierdzioS Offline
      sierdzio
      Moderators
      wrote on last edited by
      #2

      Have you tried updating your code to QtQuick 2.3 (just change the import statements), and then run it with qml exectuable?

      The old QtQuick1 code is not actively developed in Qt 5, it's only kept for compatibility reasons.

      (Z(:^

      1 Reply Last reply
      0
      • D Offline
        D Offline
        donbychang
        wrote on last edited by
        #3

        Thanks for sierdzio's reply, but it seems to be useless.
        I tried to write a simple qt app with qml, the code shows as below:
        @
        //main.cpp
        #include <QGuiApplication>
        #include <QtQuick/QQuickView>
        #include <QTextCodec>

        int main(int argc, char **argv)
        {
        QGuiApplication app(argc, argv);
        QTextCodec *codec = QTextCodec::codecForName("Utf-8");
        QTextCodec::setCodecForLocale(codec);

        QQuickView view;
        view.setSource(QUrl("qml/main.qml"));
        view.show();
        return app.exec(&#41;;
        

        }

        //main.qml
        import QtQuick 2.3
        import Qt.labs.folderlistmodel 2.0

        ListView {
        width: 200; height: 400

        FolderListModel {
            id: folderModel
            folder: "/mnt/usb"
        }
        
        Component {
            id: fileDelegate
            Text { text: fileName; font.pixelSize: 20}
        }
        
        model: folderModel
        delegate: fileDelegate
        

        }
        @
        This app can simply show the content of usb inserts on my board.
        Even I changed to QtQuick 2.0, QtQuick 2.2, or QtQuick 2.3 in the qml, it still took about 8~10 sec to show.
        Of course, other apps with qml also need to take this time.

        Is there another way to think about how to solve this problem?
        Anyway, thanks for your reply.

        1 Reply Last reply
        0
        • timdayT Offline
          timdayT Offline
          timday
          wrote on last edited by
          #4

          I note I'm in the habit of, in constructors of my QQuickView subclasses, doing:

          @
          setSurfaceType(QSurface::OpenGLSurface);
          QSurfaceFormat format;
          #ifdef MOBILE // This is something I set for OpenGLES platforms
          format.setRenderableType(QSurfaceFormat::OpenGLES);
          #else
          format.setRenderableType(QSurfaceFormat::OpenGL);
          #endif
          format.setAlphaBufferSize(8);
          format.setStencilBufferSize(8);
          setFormat(format);
          @

          Although I'm not sure how I got into the habit. Maybe a relic from QDeclarative days (is QQuickView OpenGL by default? ... I'm not actually sure).

          I just mention it because in that SO post you link, the fix is to move from drawing on a QWidget to a QGLWidget. So maybe forcing QQuickView to use OpenGL will help.

          1 Reply Last reply
          0
          • D Offline
            D Offline
            donbychang
            wrote on last edited by
            #5

            Thanks for timday's reply.
            Yesterday I tried to solve this problem with some tools, and fortunately found some good news. :)

            I used debug tool - strace to analyze my app. Here is the command :
            strace ./my_qt_app -platform eglfs

            and there was something strange...
            I saw the app would open each event located under the /dev/input/eventN,
            just like below:
            open("/dev/input/event0", O_RDONLY ...)
            open("/dev/input/event1", O_RDONLY ...)
            open("/dev/input/event2", O_RDONLY ...)
            ....

            On my target board, there were about 20 event (event0 ~ event20) for specially use. I tried to delete all the events except event0 and ran again.
            It was surprised that it only took about 4 sec to show.

            Besides, I found that the path of fonts would affect the execute time too, that is, the app load fonts from default path at /usr/share/fonts that set in the file /etc/fonts/fonts.conf on my board. If I changed the path to the Qt5.3 libary path, for example, /usr/local/Qt5.3/lib/fonts, it would reduce about 1 sec.
            Now my app needed to take about 3 sec to show, but still lower than Qt4.8.4. (it only needed to take about 1 sec)

            Therefore, now there is one more question:
            Why Qt5.3.0 would poll each event under /dev/input? (my config set error?)

            Does someone know where is the source code of this setting or can give me some direction to chase this problem?

            Anyway, thanks for your help again.

            1 Reply Last reply
            0
            • sierdzioS Offline
              sierdzioS Offline
              sierdzio
              Moderators
              wrote on last edited by
              #6

              donbychang - great investigation, thanks for sharing!

              timday QtQuick2 not only uses OpenGL by default - it cannot be run without it (OpenGL 2.0 is the minimal version).

              (Z(:^

              1 Reply Last reply
              0
              • timdayT Offline
                timdayT Offline
                timday
                wrote on last edited by
                #7

                sierdzio - ah thanks for the clarification. I think my lines of code came as part of a naive port from a QDeclarative application then (where it did used to be necessary to select OpenGL rendering explicitly).

                That does make me wonder what the other QSurface::RasterSurface option to QQuickView::setSurfaceType (ok actually inherited QWindow::setSurfaceType) would do though. Docs seem to imply some sort of less OpenGL-ey stuff being used...

                1 Reply Last reply
                0
                • JKSHJ Offline
                  JKSHJ Offline
                  JKSH
                  Moderators
                  wrote on last edited by
                  #8

                  Hi donbychang,

                  [quote]Therefore, now there is one more question:
                  Why Qt5.3.0 would poll each event under /dev/input? (my config set error?)
                  Does someone know where is the source code of this setting or can give me some direction to chase this problem?[/quote]I don't know the answer, but I'm sure the Qt engineers do. You can find them at the "Interest mailing list":http://lists.qt-project.org/mailman/listinfo/interest

                  Subscribe to the list and post your question there.

                  Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                  1 Reply Last reply
                  0
                  • D Offline
                    D Offline
                    donbychang
                    wrote on last edited by
                    #9

                    Thanks for everybody's reply.
                    I solved this problem!

                    Like I said before, I found that the application would search all the events under the /dev/input, even you don't use any input event plugin (tslib, evdevtouch, evdevkeyboard...etc). This would cause the app delay to show.

                    Therefore, I traced the source code to find where the setting is, and finally I found that in the following code:

                    //Qt5.3/qtbase/src/platformsupport/devicediscovery/qdevicediscovery_static.cpp

                    in this file, the function
                    QDeviceDiscovery::scanConnectedDevices()
                    would search /dev/input/

                    This code finally will be compiled and package as libQt5PlatformSupport.a
                    and the platform eglfs will use this.

                    In the file Qt5.3/qtbase/src/plugins/platforms/eglfs/qeglfsintegration.cpp, if there is no export variable set, that is, QT_QPA_EGLFS_DISABLE_INPUT, the plugin will set the variable mDisableInputHandlers to be false. This flag finally will start to search all event under /dev/input, and hence slow down the app to show.

                    In fact, I tried that before I ran the app, I set the export:
                    export QT_QPA_EGLFS_DISABLE_INPUT=1
                    and the app would show within 4,5 sec. This proved the setting indeed affect the speed.

                    Of course, this time still did not satisfy me, so I still used the tool strace to find another possibility. Finally I found that the font would cause the delay too. In my platform, the original font is DroidSansFallback.ttf in the /usr/local/Qt5.3/lib/fonts. When I selected another font, msyh.ttf. It was apparently that the app will show within about 1 sec. That is what I want. :)
                    By the way, if I choose this font, there is no difference that set the path in the file /etc/fonts/font.conf, that is, even I set the path to be /usr/share/fonts. The speed seems no much difference.

                    Finally, let me make 2 short conclusions:

                    1. set the flag QT_QPA_EGLFS_DISABLE_INPUT to be true, that is,
                      export QT_QPA_EGLFS_DISABLE_INPUT=1
                      before start to run the app.

                    2.check what the font you used
                    at least, use msyh.ttf is faster than DroidSansFallback.ttf in my platform.

                    I am not sure that the above comments are totally right or not, so if someone finds any wrong, please also let me know.

                    Thanks for everybody's opinion!

                    1 Reply Last reply
                    0

                    • Login

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Users
                    • Groups
                    • Search
                    • Get Qt Extensions
                    • Unsolved