Results 1 to 8 of 8

Thread: Qt 5.2 Alpha Gets Love From Bluetooth, NFC, QML

  1. #1
    Join Date
    Jan 2007
    Posts
    14,350

    Default Qt 5.2 Alpha Gets Love From Bluetooth, NFC, QML

    Phoronix: Qt 5.2 Alpha Gets Love From Bluetooth, NFC, QML

    As was expected to happen, Qt 5.2 Alpha 1 is now available for downloading. Qt 5.2 is set to introduce several new default modules, tidies up the Android and iOS support, has a new JavaScript engine for Qt QML, and there's a whole host of other changes for this leading open-source tool-kit...

    http://www.phoronix.com/vr.php?view=MTQ3MzI

  2. #2
    Join Date
    Jul 2013
    Location
    Bordeaux, France
    Posts
    286

    Default

    Quote Originally Posted by phoronix View Post
    Phoronix: Qt 5.2 Alpha Gets Love From Bluetooth, NFC, QML

    As was expected to happen, Qt 5.2 Alpha 1 is now available for downloading. Qt 5.2 is set to introduce several new default modules, tidies up the Android and iOS support, ...

    http://www.phoronix.com/vr.php?view=MTQ3MzI
    Does it compile to native code for android ? It would be good for better performance of the qt apps in comparison of other apps.

  3. #3
    Join Date
    Sep 2013
    Location
    Eastern USA
    Posts
    13

    Default

    Quote Originally Posted by doom_Oo7 View Post
    Does it compile to native code for android ? It would be good for better performance of the qt apps in comparison of other apps.
    If by "native code" you mean non-Java code, then yes. It uses the NDK and JNI to mix the native Qt C++ code with the Java interface of Android. However, using "native code" usually doesn't result in much of a speed gain (if any). Anecdotally, I haven't noticed any kind of a difference in speed between Java-only and Qt apps of a similar nature (of course, they were simple test cases that I made, nothing overly complex).

  4. #4
    Join Date
    Jul 2013
    Location
    Bordeaux, France
    Posts
    286

    Default

    Quote Originally Posted by Etzos View Post
    If by "native code" you mean non-Java code, then yes. It uses the NDK and JNI to mix the native Qt C++ code with the Java interface of Android. However, using "native code" usually doesn't result in much of a speed gain (if any). Anecdotally, I haven't noticed any kind of a difference in speed between Java-only and Qt apps of a similar nature (of course, they were simple test cases that I made, nothing overly complex).
    On which phone ? With my nexus S, Jelly bean 4.2.2 and mostly every apps are quite laggy even with no apps running...

  5. #5
    Join Date
    Sep 2013
    Location
    Eastern USA
    Posts
    13

    Default

    Quote Originally Posted by doom_Oo7 View Post
    On which phone ? With my nexus S, Jelly bean 4.2.2 and mostly every apps are quite laggy even with no apps running...
    I tested on an old Droid X2 and on a Samsung Galaxy S4.

    Just because it's "native code" doesn't mean that it can do anything much faster. It still has to go through Dalvik and interfacing from C/C++ to Java has its own overhead. The only gains you would really see are when doing things only in C/C++ (i.e. collection manipulation). Qt, by nature, has to interface with the Android SDK/NDK because it's a GUI library, so it hits the Dalvik bottleneck just the same as plain old Java.

  6. #6
    Join Date
    Nov 2012
    Posts
    145

    Default

    Quote Originally Posted by Etzos View Post
    If by "native code" you mean non-Java code, then yes. It uses the NDK and JNI to mix the native Qt C++ code with the Java interface of Android. However, using "native code" usually doesn't result in much of a speed gain (if any). Anecdotally, I haven't noticed any kind of a difference in speed between Java-only and Qt apps of a similar nature (of course, they were simple test cases that I made, nothing overly complex).

    C/C++ tends to be better at consistent performance and memory management (which can result in much better multitasking performance), but the average performance is not that different between Java or C++.

  7. #7
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    Default

    Completely on another topic, I find it interesting that they went with bluez4 given that its discontinued and bluez5 is an incompatible API break.

  8. #8
    Join Date
    Nov 2012
    Posts
    145

    Default

    Quote Originally Posted by Ericg View Post
    Completely on another topic, I find it interesting that they went with bluez4 given that its discontinued and bluez5 is an incompatible API break.
    I believe there is an abstraction layer called Solid to deal with API breakage in platform libraries, so it should be possible to switch to bluez5 with just another plugin, don't know for sure though.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •