Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
class QAbstractOpenGLFunctions (note missing Q_GUI_EXPORT) Regards, Konstantin 2014-11-26 11:42 GMT+04:00 Christophe de Dinechin christo...@taodyne.com: I'm trying to adapt Tao3D (http://tao3d.sourceforge.net) to the new way of doing OpenGL on Qt. I run into unsatisfied symbols for QAbstractOpenGLFunctions (specifically, the vtable and the destructor), despite the fact that QOpenGLFunctions_3_0 (which derives from QAbstractOpenGLFunctions) is present in the libQtGui.a library. I'm using the MinGW binaries from the installer. Why would a derived class be in the library if the base class is not? $ nm libQt5Gui.a | grep QOpenGLFunctions_3_0 I __imp___ZTV20QOpenGLFunctions_3_0 I __nm___ZTV20QOpenGLFunctions_3_0 I __imp___ZTI20QOpenGLFunctions_3_0 I __nm___ZTI20QOpenGLFunctions_3_0 T __ZN20QOpenGLFunctions_3_0D2Ev I __imp___ZN20QOpenGLFunctions_3_0D2Ev T __ZN20QOpenGLFunctions_3_0D1Ev I __imp___ZN20QOpenGLFunctions_3_0D1Ev T __ZN20QOpenGLFunctions_3_0D0Ev I __imp___ZN20QOpenGLFunctions_3_0D0Ev T __ZN20QOpenGLFunctions_3_0C2Ev I __imp___ZN20QOpenGLFunctions_3_0C2Ev T __ZN20QOpenGLFunctions_3_0C1Ev I __imp___ZN20QOpenGLFunctions_3_0C1Ev T __ZN20QOpenGLFunctions_3_025initializeOpenGLFunctionsEv I __imp___ZN20QOpenGLFunctions_3_025initializeOpenGLFunctionsEv T __ZN20QOpenGLFunctions_3_019isContextCompatibleEP14QOpenGLContext I __imp___ZN20QOpenGLFunctions_3_019isContextCompatibleEP14QOpenGLContext T __ZN20QOpenGLFunctions_3_014versionProfileEv I __imp___ZN20QOpenGLFunctions_3_014versionProfileEv $ nm libQt5Gui.a | grep QAbstractOpenGL [nothing] Christophe de Dinechin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QML instantiation performance
Hello, apologies for cross-posting. I find this such a fundamental issue that I feel at least having the best possible understanding of it worth it (if any exists, which is also a valuable information in itself). I am happy to help if there is anything I could check. thanks, Juha --- Hello, I’m having trouble going from Qt 5.1 to 5.3 / 5.4 because of a slowdown in QML (15..35% slower). This primarily relates to component instantiation and seems quite consistent across the platforms and QPAs I’ve used recently. If you have any insights, thoughts or something I could check I would highly appreciate them. I’ve tested on dual quadcore imx6 (both EGLFS and XCB) embedded platform as well as few desktop Fedoras. I’ve tested with 5.1.1, 5.3.1 and the latest 5.4.0. The slowdown varies but is fairly consistently between 15..35 %. Instantiation CPU loads do not seem to be particularly high ( 70%). Running QML profiler seems to make results less predictable. So I made a very simple application startup timer that checks main() - QQuickWindow::beforeSynchronizing() - beforeRendering() - afterRendering() - frameSwapped(). Please find my highly scientific measurements below. I slowed down the CPU to make things more clear on the desktop I’m writing this email from. This behaviour is not specific to only application startup but later runtime instantiations seem also slower. I am grateful for any thoughts or things I could check. Thanks, Juha Qt 5.1.1 low CPU qtquickcontrols gallery example startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 950 2. onBeforeRendering() time it took from beforeSynchronizing: 3 3. onAfterRendering() time it took from beforeRendering: 1572 4. onFrameSwapped() time it took from afterRendering: 5 = 2530 ms for first frame swapped. Qt 5.3.1 low CPU qtquickcontrols gallery example startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 1843 2. onBeforeRendering() time it took from beforeSynchronizing: 364 3. onAfterRendering() time it took from beforeRendering: 1039 4. onFrameSwapped() time it took from afterRendering: 83 = 3329 ms for first frame swapped. Qt 5.1.1 low CPU my application startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 809 2. onBeforeRendering() time it took from beforeSynchronizing: 3 3. onAfterRendering() time it took from beforeRendering: 1373 4. onFrameSwapped() time it took from afterRendering: 88 = 2273 ms for the first frame swapped Qt 5.3.1 low CPU my application startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 1341 2. onBeforeRendering() time it took from beforeSynchronizing: 4 3. onAfterRendering() time it took from beforeRendering: 2184 4. onFrameSwapped() time it took from afterRendering: 10 = 3539 ms for the first frame swapped ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping win32-mingw47 from the CI system, adding win32-mingw491 one
Hi, I agree with Kai's assessment. The CI should use the same mingw version as the release system. To not let this task sit forever please speak up if you care about mingw 4.7.x rather than using 4.9.x going forward. No negative comment about the plan implies universal acceptance after one week :) -- Alex From: development-bounces+alexander.blasche=theqtcompany@qt-project.org development-bounces+alexander.blasche=theqtcompany@qt-project.org on behalf of Koehne Kai kai.koe...@theqtcompany.com Sent: Tuesday, November 25, 2014 09:52 To: development@qt-project.org Subject: [Development] Dropping win32-mingw47 from the CI system, adding win32-mingw491 one Hi, I suggest we drop the win32-mingw47_developer-build-qtlibinfix-Windows configuration from the CI, and replace it by one utilizing mingw-builds i686-4.9.1-release-posix-dwarf-rt_v3-rev2 . This is in addition with the two win32-mingw48 configurations we already have in the CI system. We've been releasing Qt 5.0 with mingw-builds x32-4.7.2-release-posix-sjlj-rev8, and at this time also defined it as a 'reference' configuration. However, we've long since upgraded our binary packages to newer mingw-builds packages, for 5.1 with x32-4.8.0-release-posix-dwarf-rev2 , for 5.2 and 5.3 with i686-4.8.2-release-posix-dwarf-rt_v3-rev3 , and finally Qt 5.4 will be packaged with i686-4.9.1-release-posix-dwarf-rt_v3-rev2. I'd claim that support for mingw-builds x32-4.7.2-release-posix-sjlj-rev8 isn't all that relevant anymore. It also does break already in configurations that we don't test (namely ANGLE). The outdated mingw-w64 headers in this package do however cause problems, as seen in https://codereview.qt-project.org/#/c/100301/ . Regards Kai Kai Köhne, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: kai.koe...@theqtcompany.com | Mobile: + 49 151 55155601 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
On 26 Nov 2014, at 09:04, Konstantin Ritt ritt...@gmail.com wrote: class QAbstractOpenGLFunctions (note missing Q_GUI_EXPORT) Do you mean this is a bug, or that I'm using it wrong and it's not supposed to be visible in the library? If not, why is its destructor virtual (implying that the symbol for dtor and vtable at least should be exported). Thanks Christophe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
On Wednesday 26 Nov 2014 09:13:38 Christophe de Dinechin wrote: On 26 Nov 2014, at 09:04, Konstantin Ritt ritt...@gmail.com wrote: class QAbstractOpenGLFunctions (note missing Q_GUI_EXPORT) Do you mean this is a bug, or that I'm using it wrong and it's not supposed to be visible in the library? If not, why is its destructor virtual (implying that the symbol for dtor and vtable at least should be exported). How are you trying to use this class? It's not meant to be used directly but rather one of it's concrete subclasses. We've been using the concrete subclasses in a number of projects and have not had any problem. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
On 26 Nov 2014, at 09:46, Sean Harmer sean.har...@kdab.com wrote:
On Wednesday 26 Nov 2014 09:13:38 Christophe de Dinechin wrote:
On 26 Nov 2014, at 09:04, Konstantin Ritt ritt...@gmail.com wrote:
class QAbstractOpenGLFunctions
(note missing Q_GUI_EXPORT)
Do you mean this is a bug, or that I'm using it wrong and it's not supposed
to be visible in the library? If not, why is its destructor virtual
(implying that the symbol for dtor and vtable at least should be exported).
How are you trying to use this class? It's not meant to be used directly but
rather one of it's concrete subclasses.
I'm not using it directly. I have something that looks like this:
#include QtGlobal
#if QT_VERSION 0x050100
struct TaoOpenGLFunctions {};
// additional stuff to get glew.h
#else
# include QOpenGLFunctions_3_0
struct TaoOpenGLFunctions : QOpenGLFunctions_3_0 {};
#endif
struct OpenGLState : GraphicState, TaoOpenGLFunctions { ... }
It compiles OK, but it fails to link stating that it does not find the vtable
for QAbstractOpenGLFunctions, referenced from the compiler-generated copy
constructor for QAbstractOpenGLFunctions. Maybe the problem is that there
should be a copy constructor in the class? Even if marked private, if the
intent is that you can't copy the class (but I don't see why not).
We've been using the concrete
subclasses in a number of projects and have not had any problem.
Try with a class that has a copy constructor or with a usage pattern that
causes the compiler to generate a copy constructor.
Thanks
Christophe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
Try with a class that has a copy constructor or with a usage pattern that causes the compiler to generate a copy constructor. Which gives me a possible fix: in my TaoOpenGLFunctions, I can add a copy constructor that invokes the default constructor instead of the copy constructor. So I can solve my problem, but I still think this is a bug in QAbstractOpenGLFunctions. It should either provide a copy constructor, possibly private if you want to generate a compile-time error, or be marked as Q_GUI_EXPORT. Thanks, Christophe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
struct OpenGLState : GraphicState { TaoOpenGLFunctions *funcs; ... }
voi-la
Regards,
Konstantin
2014-11-26 13:15 GMT+04:00 Christophe de Dinechin christo...@taodyne.com:
Try with a class that has a copy constructor or with a usage pattern
that causes the compiler to generate a copy constructor.
Which gives me a possible fix: in my TaoOpenGLFunctions, I can add a copy
constructor that invokes the default constructor instead of the copy
constructor. So I can solve my problem, but I still think this is a bug in
QAbstractOpenGLFunctions. It should either provide a copy constructor,
possibly private if you want to generate a compile-time error, or be marked
as Q_GUI_EXPORT.
Thanks,
Christophe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Help needed to test Ministro 10.3, needed for Qt 5.4!
Hello folks, I have some bad news about Ministro on Android 5.0. Due to a bug https://code.google.com/p/android/issues/detail?id=79478 introduced by Google in Android 5.0 final release apps that are using Ministro are not working anymore, on Android L preview it worked just fine. I hope in the next Android version Google will fix this problem. New stuff added to Ministro 10. - application startup up speed improvement, I've cuted +150ms from the time that your application needs to wait for Ministro's response, now your application waits 2-4ms (of course if Ministro doesn't need to download/extract anything). - extract Qt 5.4 QuickControls style info - speed up the theme extraction (now it needs 2/3 of the previous time). - extract InsetDrawable. On Android 4.4.4 it seems this Drawable is used and will crash QWidget based apps if is not extracted. New stuff added to 10.1 - bumped MINISTRO_MAX_API_LEVEL New stuff added to 10.3 - for more exceptions on Android 5.0 - extract default palette fonts, needed by Qt 5.4 - extract some Android 5.0 specific look and style info. What happen with 10.2? - I bumped the version to 10.3 by mistake and I pushed it, so there was no 10.2 :). How to test it: - make sure the previous version is installed and your apps are using it. - install over the previous version ($ adb install -r Ministro\ II\ v10.3.apk). * Ministro will extract again *ONCE* the style. * Trying your existing apps should *NOT* trigger any new downloads. - after you test your applications with Ministro installed on top of previous Ministro version, please test in on a clean installation. So, go to settings - apps and remove Ministro, then install it again ($ adb install Ministro\ II\ v10.3.apk). * Ministro should extract style info and certificates and it should download again all needed libs. * Your application should work without any recompilation. Please download and test Ministro from here: https://files.kde.org/necessitas/installer/test/Ministro%20II%20v10.3.apk Thank you! Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.4.0 release coming soon
Hi all! Qt 5.4.0 release is coming soon. Target is to put RC out during this week (most probably tomorrow) and final 9th Dec 2014. Many changes files are still missing, try links from http://qt-project.org/wiki/Change-files-in-Qt-5.4.0. We need to get needed files in '5.4.0' branch as soon as possible! We need to have final packages available latest Fri 5th Dec (meaning final content in latest Thu 4th Dec) so there isn't so much time to get needed changes in... Please update known issues page here as well: http://qt-project.org/wiki/Qt540-KnownIssues Best regards, Jani Heikkinen Release Manager | The Qt Company The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, Finland Email: jani.heikki...@theqtcompany.com www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Help needed to test Ministro 10.3, needed for Qt 5.4!
Please star the android issue so that Google developers understand the severity of the problem. It's not like only six people are affected by this. Cheers, Cristian. On 26 Nov 2014 12:45, BogDan bog_dan...@yahoo.com wrote: Hello folks, I have some bad news about Ministro on Android 5.0. Due to a bug https://code.google.com/p/android/issues/detail?id=79478 introduced by Google in Android 5.0 final release apps that are using Ministro are not working anymore, on Android L preview it worked just fine. I hope in the next Android version Google will fix this problem. New stuff added to Ministro 10. - application startup up speed improvement, I've cuted +150ms from the time that your application needs to wait for Ministro's response, now your application waits 2-4ms (of course if Ministro doesn't need to download/extract anything). - extract Qt 5.4 QuickControls style info - speed up the theme extraction (now it needs 2/3 of the previous time). - extract InsetDrawable. On Android 4.4.4 it seems this Drawable is used and will crash QWidget based apps if is not extracted. New stuff added to 10.1 - bumped MINISTRO_MAX_API_LEVEL New stuff added to 10.3 - for more exceptions on Android 5.0 - extract default palette fonts, needed by Qt 5.4 - extract some Android 5.0 specific look and style info. What happen with 10.2? - I bumped the version to 10.3 by mistake and I pushed it, so there was no 10.2 :). How to test it: - make sure the previous version is installed and your apps are using it. - install over the previous version ($ adb install -r Ministro\ II\ v10.3.apk). * Ministro will extract again *ONCE* the style. * Trying your existing apps should *NOT* trigger any new downloads. - after you test your applications with Ministro installed on top of previous Ministro version, please test in on a clean installation. So, go to settings - apps and remove Ministro, then install it again ($ adb install Ministro\ II\ v10.3.apk). * Ministro should extract style info and certificates and it should download again all needed libs. * Your application should work without any recompilation. Please download and test Ministro from here: https://files.kde.org/necessitas/installer/test/Ministro%20II%20v10.3.apk Thank you! Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt downloads now moved to qt.io
Hello, As part of the website updates, the download page on qt-project.org is now redirected to qt.io. You can read the details at the blog (which will also move to a qt.io address in the near future). http://blog.qt.digia.com/blog/2014/11/26/qt-downloads-moving-to-qt-io/ Best regards, Tero Kojo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
On 26 Nov 2014, at 10:21, Konstantin Ritt ritt...@gmail.com wrote:
struct OpenGLState : GraphicState { TaoOpenGLFunctions *funcs; ... }
voi-la
Nope: I don't inherit the GL functions that way, so I have to rewrite every
glFoo as funcs-glFoo, which is double plus annoying. And then, there are
enough levels of indirection in the existing implementation as is, no need to
add One More Level Of Indirection™ ;-)
The copy constructor trick did it, though, so my recommendation would be to add
a copy constructor to QAbstractOpenGLFunctions.
Thanks for the help,
Christophe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Clarification needed for Qt Script's future over QJSEngine/Value
I was looking at using QtScript for a project and noticed that all work has been ABANDONED for using the new java script engine V8 as noted in http://qt-project.org/wiki/V8_Port and then pouring over other bug reports the mailing list about QtScript and how QtScript won't be updated to use a newer JavaScriptCore since it would be too much work to maintain. The talk is that for Qt5 there is QJSEngine/Value API instead, but, that is a smaller subset of features over what QtScript offers now. Reading about QJSEngine/Value there seems to be no official API way for exposing a C type callback, so everything has to go through QObject bindings instead, correct? Does this mean that QtScript will eventually be deprecated in favor of QJSEngine/Value since QtScript will not be updated any longer with any improvements and basically be left in a as is state with possible bug fixes? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
Hi, You are right, we need to add a few more features to QJSEngine. I'm not so much in favor of the default prototype for meta type api anymore, as it promotes the creation of slow conversion code I think. If you peek at my gerrit dashboard then you can see that I'm about 80% done with a series for gadget support that will allow you to expose your own value types without a conversion needed. In theory we could build that up with some help from moc to the extend that the jit accesses your Q_PROPERTY members directly. I'm hesitant to expose engine internals because that really hurt us last time. But I'm all in favor of adding some of the qml extension js APIs by default, such as qlocale extensions etc. There's some low hanging fruit there, so contributions are welcome :) Simon Original Message From: N. N. Sent: Wednesday, November 26, 2014 19:51 To: development@qt-project.org Reply To: N. N. Subject: [Development] Clarification needed for Qt Script's future over QJSEngine/Value I was looking at using QtScript for a project and noticed that all work has been ABANDONED for using the new java script engine V8 as noted in http://qt-project.org/wiki/V8_Port and then pouring over other bug reports the mailing list about QtScript and how QtScript won't be updated to use a newer JavaScriptCore since it would be too much work to maintain. The talk is that for Qt5 there is QJSEngine/Value API instead, but, that is a smaller subset of features over what QtScript offers now. Reading about QJSEngine/Value there seems to be no official API way for exposing a C type callback, so everything has to go through QObject bindings instead, correct? Does this mean that QtScript will eventually be deprecated in favor of QJSEngine/Value since QtScript will not be updated any longer with any improvements and basically be left in a as is state with possible bug fixes? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
On Wednesday, 26 November 2014, 14:15, Hausmann Simon simon.hausm...@theqtcompany.com wrote: Hi, You are right, we need to add a few more features to QJSEngine. I'm not so much in favor of the default prototype for meta type api anymore, as it promotes the creation of slow conversion code I think. If you peek at my gerrit dashboard then you can see that I'm about 80% done with a series for gadget support that will allow you to expose your own value types without a conversion needed. I am wondering if just going directly to V8 instead of using Qt as the middle man would be the best course of action, that way you get all the speed benefits that V8 offers, and no need to mess with any conversion code, with the only disadvantage, that I can think of, is adding another dependency. Or, will this introduce linker errors with Qt's version of V8, if all we need is QtCore.lib QtGui.lib? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 release coming soon
On Wed, Nov 26, 2014 at 3:50 AM, Heikkinen Jani jani.heikki...@theqtcompany.com wrote: Hi all! Qt 5.4.0 release is coming soon. Target is to put RC out during this week (most probably tomorrow) and final 9th Dec 2014. Many changes files are still missing, try links from http://qt-project.org/wiki/Change-files-in-Qt-5.4.0. We need to get needed files in '5.4.0' branch as soon as possible! We need to have final packages available latest Fri 5th Dec (meaning final content in latest Thu 4th Dec) so there isn't so much time to get needed changes in... Where's the correct place to file a bug about a changelog entry being incorrect? Specifically, the bug # in the following entry doesn't seem to have anything to do with the changelog item: - [QTBUG-41192] Fixed menu item shortcuts without keyboard modifiers. Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 release coming soon
On Wednesday 26 November 2014 12:33:52 Adam Light wrote: On Wed, Nov 26, 2014 at 3:50 AM, Heikkinen Jani jani.heikki...@theqtcompany.com wrote: Hi all! Qt 5.4.0 release is coming soon. Target is to put RC out during this week (most probably tomorrow) and final 9th Dec 2014. Many changes files are still missing, try links from http://qt-project.org/wiki/Change-files-in-Qt-5.4.0. We need to get needed files in '5.4.0' branch as soon as possible! We need to have final packages available latest Fri 5th Dec (meaning final content in latest Thu 4th Dec) so there isn't so much time to get needed changes in... Where's the correct place to file a bug about a changelog entry being incorrect? Specifically, the bug # in the following entry doesn't seem to have anything to do with the changelog item: - [QTBUG-41192] Fixed menu item shortcuts without keyboard modifiers. Nowhere. Just tell us (me) what the correct one should be and we'll update the changelog. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
On Wednesday 26 November 2014 19:59:55 N. N. wrote: On Wednesday, 26 November 2014, 14:15, Hausmann Simon simon.hausm...@theqtcompany.com wrote: Hi, You are right, we need to add a few more features to QJSEngine. I'm not so much in favor of the default prototype for meta type api anymore, as it promotes the creation of slow conversion code I think. If you peek at my gerrit dashboard then you can see that I'm about 80% done with a series for gadget support that will allow you to expose your own value types without a conversion needed. I am wondering if just going directly to V8 instead of using Qt as the middle man would be the best course of action, that way you get all the speed benefits that V8 offers, and no need to mess with any conversion code, with the only disadvantage, that I can think of, is adding another dependency. Or, will this introduce linker errors with Qt's version of V8, if all we need is QtCore.lib QtGui.lib? Since Qt doesn't use V8 anymore, there should not be any clashes at all. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 release coming soon
On Wed, Nov 26, 2014 at 2:26 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 26 November 2014 12:33:52 Adam Light wrote: Where's the correct place to file a bug about a changelog entry being incorrect? Specifically, the bug # in the following entry doesn't seem to have anything to do with the changelog item: - [QTBUG-41192] Fixed menu item shortcuts without keyboard modifiers. Nowhere. Just tell us (me) what the correct one should be and we'll update the changelog. I have no idea what the correct bug is for that commit, only that the referenced bug does seem to have anything to do with menu item shortcuts. Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FOSDEM 2015
Guys, Less than 10 days for the deadline for the Desktops DevRoom at FOSDEM 2015 and not a single Qt-related talk submited. I cannot really believe nobody has anything to say! Call for Talks: http://www.elpauer.org/2014/10/fosdem-2015-desktops-devroom-call-for-talks/ -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 release coming soon
On Wednesday 26 November 2014 15:54:35 Adam Light wrote: On Wed, Nov 26, 2014 at 2:26 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 26 November 2014 12:33:52 Adam Light wrote: Where's the correct place to file a bug about a changelog entry being incorrect? Specifically, the bug # in the following entry doesn't seem to have anything to do with the changelog item: - [QTBUG-41192] Fixed menu item shortcuts without keyboard modifiers. Nowhere. Just tell us (me) what the correct one should be and we'll update the changelog. I have no idea what the correct bug is for that commit, only that the referenced bug does seem to have anything to do with menu item shortcuts. Fair enough. https://codereview.qt-project.org/100882 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML instantiation performance
Hi Juha, For some more light on this issue, are you able to run the qtdeclarative/tests/benchmarks/qml/librarymetrics_performance benchmark on both 5.1 and 5.3 (you may have to backport to 5.1 as IIRC I made some changes to the way the components were instantiated for 5.2 before the benchmark was integrated, but I may be wrong about that. It was originally written prior to Qt5.0 release so with some minor changes it will definitely work against 5.1). The benchmarks are quite granular, and should allow you to see precisely which part of the component instantiation is significantly slower. Kind regards, Chris Adams. www.qinetic.com.au - Qt And QML User Experience Specialists On Wed, Nov 26, 2014 at 6:08 PM, Juha Vuolle juvuo...@gmail.com wrote: Hello, apologies for cross-posting. I find this such a fundamental issue that I feel at least having the best possible understanding of it worth it (if any exists, which is also a valuable information in itself). I am happy to help if there is anything I could check. thanks, Juha --- Hello, I’m having trouble going from Qt 5.1 to 5.3 / 5.4 because of a slowdown in QML (15..35% slower). This primarily relates to component instantiation and seems quite consistent across the platforms and QPAs I’ve used recently. If you have any insights, thoughts or something I could check I would highly appreciate them. I’ve tested on dual quadcore imx6 (both EGLFS and XCB) embedded platform as well as few desktop Fedoras. I’ve tested with 5.1.1, 5.3.1 and the latest 5.4.0. The slowdown varies but is fairly consistently between 15..35 %. Instantiation CPU loads do not seem to be particularly high ( 70%). Running QML profiler seems to make results less predictable. So I made a very simple application startup timer that checks main() - QQuickWindow::beforeSynchronizing() - beforeRendering() - afterRendering() - frameSwapped(). Please find my highly scientific measurements below. I slowed down the CPU to make things more clear on the desktop I’m writing this email from. This behaviour is not specific to only application startup but later runtime instantiations seem also slower. I am grateful for any thoughts or things I could check. Thanks, Juha Qt 5.1.1 low CPU qtquickcontrols gallery example startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 950 2. onBeforeRendering() time it took from beforeSynchronizing: 3 3. onAfterRendering() time it took from beforeRendering: 1572 4. onFrameSwapped() time it took from afterRendering: 5 = 2530 ms for first frame swapped. Qt 5.3.1 low CPU qtquickcontrols gallery example startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 1843 2. onBeforeRendering() time it took from beforeSynchronizing: 364 3. onAfterRendering() time it took from beforeRendering: 1039 4. onFrameSwapped() time it took from afterRendering: 83 = 3329 ms for first frame swapped. Qt 5.1.1 low CPU my application startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 809 2. onBeforeRendering() time it took from beforeSynchronizing: 3 3. onAfterRendering() time it took from beforeRendering: 1373 4. onFrameSwapped() time it took from afterRendering: 88 = 2273 ms for the first frame swapped Qt 5.3.1 low CPU my application startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 1341 2. onBeforeRendering() time it took from beforeSynchronizing: 4 3. onAfterRendering() time it took from beforeRendering: 2184 4. onFrameSwapped() time it took from afterRendering: 10 = 3539 ms for the first frame swapped ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML instantiation performance
Hey Chris, Thanks heaps. I'll have a look and get back with any findings (may take a day or two before I get to it). cheers, Juha 2014-11-27 3:51 GMT+02:00 Chris Adams chris.ad...@qinetic.com.au: Hi Juha, For some more light on this issue, are you able to run the qtdeclarative/tests/benchmarks/qml/librarymetrics_performance benchmark on both 5.1 and 5.3 (you may have to backport to 5.1 as IIRC I made some changes to the way the components were instantiated for 5.2 before the benchmark was integrated, but I may be wrong about that. It was originally written prior to Qt5.0 release so with some minor changes it will definitely work against 5.1). The benchmarks are quite granular, and should allow you to see precisely which part of the component instantiation is significantly slower. Kind regards, Chris Adams. www.qinetic.com.au - Qt And QML User Experience Specialists On Wed, Nov 26, 2014 at 6:08 PM, Juha Vuolle juvuo...@gmail.com wrote: Hello, apologies for cross-posting. I find this such a fundamental issue that I feel at least having the best possible understanding of it worth it (if any exists, which is also a valuable information in itself). I am happy to help if there is anything I could check. thanks, Juha --- Hello, I’m having trouble going from Qt 5.1 to 5.3 / 5.4 because of a slowdown in QML (15..35% slower). This primarily relates to component instantiation and seems quite consistent across the platforms and QPAs I’ve used recently. If you have any insights, thoughts or something I could check I would highly appreciate them. I’ve tested on dual quadcore imx6 (both EGLFS and XCB) embedded platform as well as few desktop Fedoras. I’ve tested with 5.1.1, 5.3.1 and the latest 5.4.0. The slowdown varies but is fairly consistently between 15..35 %. Instantiation CPU loads do not seem to be particularly high ( 70%). Running QML profiler seems to make results less predictable. So I made a very simple application startup timer that checks main() - QQuickWindow::beforeSynchronizing() - beforeRendering() - afterRendering() - frameSwapped(). Please find my highly scientific measurements below. I slowed down the CPU to make things more clear on the desktop I’m writing this email from. This behaviour is not specific to only application startup but later runtime instantiations seem also slower. I am grateful for any thoughts or things I could check. Thanks, Juha Qt 5.1.1 low CPU qtquickcontrols gallery example startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 950 2. onBeforeRendering() time it took from beforeSynchronizing: 3 3. onAfterRendering() time it took from beforeRendering: 1572 4. onFrameSwapped() time it took from afterRendering: 5 = 2530 ms for first frame swapped. Qt 5.3.1 low CPU qtquickcontrols gallery example startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 1843 2. onBeforeRendering() time it took from beforeSynchronizing: 364 3. onAfterRendering() time it took from beforeRendering: 1039 4. onFrameSwapped() time it took from afterRendering: 83 = 3329 ms for first frame swapped. Qt 5.1.1 low CPU my application startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 809 2. onBeforeRendering() time it took from beforeSynchronizing: 3 3. onAfterRendering() time it took from beforeRendering: 1373 4. onFrameSwapped() time it took from afterRendering: 88 = 2273 ms for the first frame swapped Qt 5.3.1 low CPU my application startup: 1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 1341 2. onBeforeRendering() time it took from beforeSynchronizing: 4 3. onAfterRendering() time it took from beforeRendering: 2184 4. onFrameSwapped() time it took from afterRendering: 10 = 3539 ms for the first frame swapped ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Help needed to test Ministro 10.3, needed for Qt 5.4!
Hi, Well the bug-type is Defect and is still opened, so, we'll have to wait for the next version and see what happens. A similar problem I've had with Android 3.0, back them they've screwed .dex class loading, but they've fixed in the next version. Cheers, BogDan. From: Harri Pasanen ha...@mpaja.com To: Cristian Adam cristian.a...@gmail.com; BogDan bog_dan...@yahoo.com Cc: Qt Development Group development@qt-project.org; Necessitas Devel necessitas-de...@kde.org; Android Development android-developm...@qt-project.org Sent: Wednesday, November 26, 2014 8:08 PM Subject: Re: [Development] Help needed to test Ministro 10.3, needed for Qt 5.4! Hmm... looking at the issue it seems to me that it is not going to be fixed, it is an intentional change. They are tightening the platform from security point of view, and this change is similar to change that made removable SD cards much less useful in KitKat: https://plus.google.com/+TodLiebeck/posts/gjnmuaDM8sn http://developer.android.com/reference/android/content/Context.html#MODE_WORLD_READABLE says it has been deprecated since API level 17, so I doubt they'll bring it back. Ministro has had a good run, but unless I'm mistaken this basically kills it? Harri On 26/11/2014 13:28, Cristian Adam wrote: Please star the android issue so that Google developers understand the severity of the problem. It's not like only six people are affected by this. Cheers, Cristian. On 26 Nov 2014 12:45, BogDan bog_dan...@yahoo.com wrote: Hello folks, I have some bad news about Ministro on Android 5.0. Due to a bug https://code.google.com/p/android/issues/detail?id=79478 introduced by Google in Android 5.0 final release apps that are using Ministro are not working anymore, on Android L preview it worked just fine. I hope in the next Android version Google will fix this problem. New stuff added to Ministro 10. - application startup up speed improvement, I've cuted +150ms from the time that your application needs to wait for Ministro's response, now your application waits 2-4ms (of course if Ministro doesn't need to download/extract anything). - extract Qt 5.4 QuickControls style info - speed up the theme extraction (now it needs 2/3 of the previous time). - extract InsetDrawable. On Android 4.4.4 it seems this Drawable is used and will crash QWidget based apps if is not extracted. New stuff added to 10.1 - bumped MINISTRO_MAX_API_LEVEL New stuff added to 10.3 - for more exceptions on Android 5.0 - extract default palette fonts, needed by Qt 5.4 - extract some Android 5.0 specific look and style info. What happen with 10.2? - I bumped the version to 10.3 by mistake and I pushed it, so there was no 10.2 :). How to test it: - make sure the previous version is installed and your apps are using it. - install over the previous version ($ adb install -r Ministro\ II\ v10.3.apk). * Ministro will extract again *ONCE* the style. * Trying your existing apps should *NOT* trigger any new downloads. - after you test your applications with Ministro installed on top of previous Ministro version, please test in on a clean installation. So, go to settings - apps and remove Ministro, then install it again ($ adb install Ministro\ II\ v10.3.apk). * Ministro should extract style info and certificates and it should download again all needed libs. * Your application should work without any recompilation. Please download and test Ministro from here: https://files.kde.org/necessitas/installer/test/Ministro%20II%20v10.3.apk Thank you! Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Necessitas-devel mailing list necessitas-de...@kde.org https://mail.kde.org/mailman/listinfo/necessitas-devel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
