[Development] D-Bus minimum version for Qt 5.6
Hi, I'm writing this both as a question to the QtDBus maintainers and as a PSA for people using QtDBus and possibly experiencing instability after upgrading to Qt 5.6. I'm afraid some important piece of information may have been left out for users who are not building their own dbus libraries or running the latest linux distros: that using QtDBus in 5.6.0 or later requires you to use at least dbus 1.8.0 to be stable. I've started experiencing random crashes inside malloc()/free() after upgrading to almost-tip-of 5.6.1 (qtbase hash http://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.6.1=adf85c09b46eaf55dab362e17e3b0828fb509750), specifically for processes that are exposing dbus services and objects. These crashes were during normal execution in totally random and seemingly innocent places, like when allocating the QArrayData for a QString (which I could confirm had valid content), or creating a QList node, etc, and complaining that malloc() had detected a memory corruption. But it always occurred either in the QDBusConnectionManager thread, or when processing a dbus method call for one of the exposed objects. I've tried running my processes under valgrind/memcheck, running clang analysis tools, etc., and couldn't find anything wrong with my code or the QtDBus code. All the instability disappeared if I reverted to Qt 5.5 using the same code, and it would also become unreproducible as I tried adding more debugging output or running it under valgrind or gdb. So this was a pretty clear sign of some sort of threading issue or race condition somewhere. I eventually tracked it down to the version of dbus used: our system runs on Ubuntu 12.04 LTS, using the package-provided libdbus which is version 1.4.8. Looking at the documentation about threading support, there's a very clear warning in the docs for dbus_threads_init_default(): Since D-Bus 1.7 it is safe to call this function from any thread, any number of times (but it must be called before any other libdbus API is used). In D-Bus 1.6 or older, this function must be called in the main thread before any other thread starts. As a result, it is not sufficient to call this function in a library or plugin, unless the library or plugin imposes a similar requirement on its callers. ( https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#ga33b6cf3b8f1e41bad5508f84758818a7 ) There's also several threads on the dbus ml archives mentionning that versions under 1.5.10 are completely unsafe to use in a multi-threaded environment, for example: https://lists.freedesktop.org/archives/dbus/2012-May/015126.html So I think the problem with QtDBus in 5.6 is that now all connection handling always happens in a background thread (QDBusConnectionManager), so even if your application runs all in a single thread, there's still going to be multi-threading by QtDBus itself. And to make things worse, QtDBus does exactly what the dbus documentation warns not to do for versions before 1.7: it calls dbus_threads_init_default() in a thread that is not the main thread (it's called at the beginning of the QDBusConnectionManager thread). Note that we've also seen similar crashes with dbus 1.6.18, which is the version that Ubuntu 14.04 ships, even though they're much harder to reproduce. Since then I've added dbus 1.10.8 into our dependencies built from source instead of the using the system one, and so far I haven't experienced instability anymore. So I wonder if anybody else has experienced something similar. Maybe there's something specific to our platform and/or code that makes this more prominent, but in any case it does look like the change of implementation in QtDBus with 5.6 is incompatible with dbus <1.7 according to the dbus docs themselves. Am I correct? If so, I think the bare minimum would be to have this mentionned prominently somewhere in the documentation. I've also noticed that qtbase/configure has a MIN_DBUS_1_VERSION variable that is currently set to 1.2, maybe this should be bumped to 1.8 as well. I'm also curious how widespread this issue could be, especially for embedded platforms where it's less likely that the OS and dependencies get updated often. And given that 12.04 LTS is still supported until 2017 it's not unreasonable to expect customers to still be using it. Thanks for your feedback, Romain Pokrzywka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Made with Qt - Bluescape at TED 2016
Hi all, I just wanted to share this piece of news, as a serious piece of hardware and UI is currently featured in the main lobby of the TED 2016 conference in Vancouver, and it's all made with Qt! https://www.bluescape.com/press/bluescape-introduces-visual-collaborative-workspace-to-1350-attendees-at-ted2016/ I've also attached a picture of the Bluescape Wall that was set up over there (sorry for the poor quality, it had to be under 100kb). It's a 3x5 array of 55'' multitouch displays sporting a total resolution of 9600x3240 pixels, and running on a 3-GPU machine (one GPU per row). It's running Qt 5.5 and makes a big use of QtQuick2 and QtWebEngine. There's also two 84'' single-display units on each side. Kudos to all contributors in the Qt community for making Qt such an awesome development framework, and special thanks to the folks at The Qt Company and KDAB. Hopefully we'll have a chance to showcase it again at the Qt World Summit in San Francisco this fall! Cheers, Romain ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] repository for the toolwrapper
It would have been a good idea to ask a native English speaker before deciding on the name, as this is an atrocity, language-wise. I'm not a native myself but I can tell this sounds wrong. 'Chose' is definitely not the right verb here, you probably wanted 'select' instead? On top of that, IMO the *er suffix sounds really odd for a command tool. Have you ever heard of commands named 'lister', 'deleter', or 'grepper' ? For these reasons I think other suggested names such as 'q[t]ver' or 'q[t]select' are much more appropriate and sound more standard. (I don't care much for q vs qt though) I hope it's not too late the rename the tool and repository, as the current name really doesn't cut it for me, and I think for a majority of English speakers. Tim, Sean, John, others, what do you think? :-) On Nov 27, 2012 6:20 AM, Knoll Lars lars.kn...@digia.com wrote: qtchooser is ok for me. Sergio, can you help to create the repo, please? Thanks, Lars On Nov 27, 2012, at 3:12 PM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 27 de novembro de 2012 11.23.00, Oswald Buddenhagen wrote: qtchooser (i kinda like that) qtswitcher I like those two. So requesting it as qtchooser. I'll rename the tool to match the repository name. -- 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 ___ 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] QT.module.rpath is not used properly
Ossi's new version of the change fixes both issues now, it should land soon hopefully. Thanks for reporting and helping identify the problem! Regards, Romain On Nov 7, 2012 2:08 AM, Thomas Senyk thomas.se...@pelagicore.com wrote: On Tue, November 06, 2012 08:21:24 PM Oswald Buddenhagen wrote: On Tue, Nov 06, 2012 at 06:17:04PM +0100, Thomas Senyk wrote: I got a self-written mkspec for the rasp-pi and everything is working as expected. With one exception, for external applications he is not adding the proper -Wl,-rpath,prefix The problem is that: cat /usr/local/Trolltech/Qt5-rasp-pi-2/mkspecs/modules/qt_lib_* |grep rpath returns nothing. that's not the problem. If you add a module to QT in your project file, qt_functions.prf:93 will add: -Wl,-rpath,SYSROOT!!/prefix *that* is the problem. the fallback path doesn't account for sysroots. and it cannot do that cleanly. so it should be scrapped. but isn't that what the patch tried to do by using $$[QT_INSTALL_LIBS/raw] ? QT_.../raw variables are variables without SYSROOT-prefix, right? I've no real clue about what qt_module.prf does and how it works ... but if it's the one taking care about preparing the installed versions of module-pri- files then the second part of the patch looks like dealing with the root problem. (the fact that QT.module.rpath) is missing. IMO the problem is not the fallback in qt_function.prf, it's the fact that the fallback is trigger. ... but hey, I'm clearly no expert on the whole module-mkspecs-architecture .. what ever you decide is good with me as long as I get a proper -rpath in the end ;) Greest Thomas ___ 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT.module.rpath is not used properly
I have a fix for this issue in Gerrit which has been waiting for weeks: https://codereview.qt-project.org/35394 But it hasn't been approved yet because apparently ossi thinks the commit log isn't clear enough. Maybe you can explain it to him in better words than I do. Romain On Nov 6, 2012 9:27 AM, Thomas Senyk thomas.se...@pelagicore.com wrote: Hi Folks, I got a self-written mkspec for the rasp-pi and everything is working as expected. With one exception, for external applications he is not adding the proper -Wl,-rpath,prefix The problem is that: cat /usr/local/Trolltech/Qt5-rasp-pi-2/mkspecs/modules/qt_lib_* |grep rpath returns nothing. -- the installed module pri files do not contain the rpath and rpath-link variables anymore. The ones in the qt-build-directory do. e.g.: qt_lib_core.pri contains: QT.core.rpath = /usr/local/Trolltech/Qt5-rasp-pi-2/lib Any though how/why they vanished? FYI: If you add a module to QT in your project file, qt_functions.prf:93 will add: -Wl,-rpath,SYSROOT!!/prefix ...which is totally wrong... but maybe expected if QT.module.rpath is empty? Greets Thomas ___ 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] Qt 5 file hierarchy
On Friday, September 21, 2012 06:01:28 PM Thiago Macieira wrote: The Qt 5 file hierarchy upon installation should be: bin/ - executables run by the user - unversioned applications, like assistant, linguist, qdbus, qdbusviewer - versioned applications, like qmake[35], qdoc5, qmlviewer5, maybe moc5, uic5, rcc5 doc/ - gone to share/qt5/doc examples/ - gone to share/qt5/examples include/ - versioned include dirs: QtCore5 or QtCore-5 or QtCore.5 or Qt5Core/ [...] Qt/ - gone, forever, no replacement imports/ - horribly flawed design, see below lib/ - arch-specific files (also libqual or lib/arch/) ./ - versioned libraries (.a, .so, .la, .prl) pkgconfig/ - versioned .pc files qt5/ - arch-specific support files: bin/ or libexec/ - executables not run by the user, like syncqt, lrelease, lupdate imports/ - QtDeclarative imports qml2/ - QML2 (including QtQuick2) arch-specific imports mkspecs/ ? share/- arch-independent files qml2/- QML2 (including QtQuick2) arch-independent imports qt5/ doc/ examples/ mkspecs/? Note on imports: the design is flawed. It was flawed in Qt 4 and it's worse now on Qt 5. For Qt 4, the flaw was that it did not differentiate QML imports that were arch-independent from the ones that required plugins. With Qt 5, it becomes worse because Qt Quick 1 and 2 share the same directory. Instead, I recommend we immediately change QML2 to the system that Perl uses: put the arch-specific files inside the lib hierarchy, for which distributions have already solved the multiarch problem, but put arch-independent files in the share hierarchy. In addition, the loader should be clever to merge similar names from the two different paths. That is, imagine a .qml file in share/qml2 that requires a plugin: if the loader is a 32-bit application, it would search for the plugin in lib/qt5/qml2, but if it's a 64-bit application it would search in lib64/qt5/qml2. Additionally, if we're still using QML2 by the Qt 6 release, the plugins could be made available in lib/qt6/qml2. As for mkspecs, I believe they should be in share, since they are technically- speaking arch-independent. +1, especially the mkspecs part. Cheers, Romain -- Romain Pokrzywka | rom...@kdab.com | Senior Qt Software Engineer Trainer 303 Twin Dolphin Dr., Redwood City, CA-94065 KDAB (USA) LLC, 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] Proposing reversal of the Math3D qreal-float change
On Thursday, September 13, 2012 07:14:50 AM lars.kn...@nokia.com wrote: On Sep 13, 2012, at 2:07 AM, ext Romain Pokrzywka romain.pokrzy...@kdab.com wrote: On Wednesday, September 12, 2012 07:10:52 AM lars.kn...@nokia.com wrote: On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu- chemnitz.de wrote: On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote: On 11/09/2012 13:34, Thiago Macieira wrote: I propose we revert it. I propose we (I) fix the affected classes in QtMultimedia and Qt3D. I'm away on business this week but I will make a start asap. I believe I mentioned that before. Anyway: I think there are (medium term) only two acceptable solutions, none of them perfect: (a) keep everything as it is (or, rather, was) (b) have fully functional real/double verticals (c) Turn qreal into a double everywhere This was rejected before by some, because it might make things slower on ARM, but would have the advantage that it's fully source compatible with Qt 4, solves the mess and would allow us to introduce floating point types where required later. Only minuses I can see are (c1) the names of QXxxF classes which are double and not float based (c2) possibly slower execution on ARM (c3) Somewhat higher memory consumption on ARM (c1) is not easily fixed. But (c2) seems to be less of an issue these days. At least for the Cortex A9 ARM claims very good double precision support. Older CPUs also have some support through VFPv2/3. (c3) should also become less and less of an issue moving forward. So to bring this up again: How about turning qreal into a typedef for double on all platforms and remove the mess this way? Whereever we need (or want to use) floats, let's use them explicitly. I think the statements might make things slower on ARM and seems to be less of an issue these days are a little misleading and too optimistic. From my own experience, using double on ARM has a serious impact on performance at many levels: data size, code generation, and even FPU options. Indeed, from what I've read it seems like the Cortex-A9 is significantly closing the gap between float and double (although not eliminating it), but's it's really the only platform that does. [1] True, but more and more embedded systems will start using that platform. My main proposal is that the default (and supported) build of Qt on ARM uses doubles for qreal. If we keep the typedef, you could still typedef it to use float at your own risk :) True, that would be a good enough solution, e.g. as an option to configure Every other platform, Cortex-A8 and previous ARM architectures, and even Intel Atom, will suffer badly from switching from floats to doubles, even though they have VFP. This is mainly due to the crappy VFP abilities in those platforms, combined with the Cortex-A8 allowing use of the NEON co-processor as the FPU, with massive performance improvements over VFP, but only available for floats. [2] And it gets even worse when using -mfloat-abi=softfp. [3] Yes, but softfp doesn't make sense with Qt Quick 2 anyway. Now, considering that most usage of Qt on embedded platforms is either through QGraphicsView or Qt Quick (1 and 2), both of them relying heavily on floating point calculations (coordinate systems, painting with AA...), this is definitely a decision with a potentially serious impact on most embedded platforms. One solution here is to explicitly use floats internally in Qt wherever possible and where it's critical to performance. One may still argue that Qt5 should be targeting the latest and future platforms instead of legacy and current ones. Fair enough. But I think the consequences should be stressed more. Some extensive benchmarking would be nice too, before deciding on one solution against the other. As said above: It's about the default build that the Qt Project tests and supports. We can keep the option of forcing qreal to float at least for now or until we've proven that the performance impact is acceptable. Yep, I'm happy with that :) Thx, Romain Cheers, Lars [1] http://www.360doc.com/content/12/0806/14/350555_228637047.shtml [2] http://processors.wiki.ti.com/index.php/Cortex_A8#Neon_and_VFP_both_suppor t_floating_point.2C_which_should_I_use.3F [3] http://wiki.debian.org/ArmHardFloatPort/VfpComparison Regards, Romain Cheers, Lars Version (a) means the current mess will go on. but it has the distict charme of (a.1) not breaking anyones existing code and (a.2) sticking to feature freeze rules. Version (b) is somewhat closer to a proper solution, but fails (a.1) and (a.2). It has also the disadvantage of requiring real work, and therefore to tie up resources. Even with my usual let's break feature freeze if the feature is cool enough hat on, I am tempted to lean
Re: [Development] Proposing reversal of the Math3D qreal-float change
On Wednesday, September 12, 2012 09:20:15 AM marco.bu...@nokia.com wrote: On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu- chemnitz.de wrote: Version (a) means the current mess will go on. but it has the distict charme of (a.1) not breaking anyones existing code and (a.2) sticking to feature freeze rules. If somebody porting his app to ARM he will be surprised, because we change qreal to float. Sorry, this is cross platform magic. Actually change qreal explicitly to double is much better, because it is explicit. No this won't change anything, because qreal is already float on ARM platforms. I would opt for a explicit removal of qreal and exchange it with double! ___ 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cross compiling Qt 5
On Sunday, August 19, 2012 11:51:05 AM Peter =?ISO-8859-1?Q?K=FCmmel?= wrote: Here a proposal: 1. -target-mkspec : specify mkspec name 2. -target : specify toolchain prefix -toolchain-prefix sounds much more appropriate than -target (which to me means the target hardware platform) 3. isn't sysroot specified by the toolchain compiler? No. At best it knows where to find its own C runtime and internals, but that's unrelated to the target sysroot, where you have all the cross-compiled system libraries and dependencies (opengl drivers, openssl...). That's what -sysroot is for. 4. not needed What about platform options, QPA plugins to build, etc. ? That said, I agree that in second look the -device-options solution isn't great, and offloads work to the mkspecs which isn't the right thing to do. I'd much prefer discrete options like we had for QWS, e.g. -plugin-mouse-tslib and so on. Just my 2c for when we switch buildsystems :) Romain ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Qt 4.9 release
On Wednesday, August 15, 2012 08:36:35 PM Thiago Macieira wrote: On quarta-feira, 15 de agosto de 2012 22.05.02, Konstantin Tokarev wrote: From wiki: QPA on Qt4.8 only makes sense on OpenGL Hardware! If you don?t have OpenGL HW there is absolutely no point in choosing Qt4.8-QPA over Qt4.8-QWS The wiki is wrong. There's a lot of reason for choosing QPA, regardless of OpenGL support or lack thereof. There are also reasons for choosing QWS instead of QPA, even with OpenGL hardware, if those reasons are stronger than the best adaptation to OpenGL (example: the QWS display server). Seconded, that wiki line is BS. Using QPA with the linuxfb plugin on 4.8 for single-process applications is way more efficient than QWS, both memory- and FPS-wise. QWS enables composition and server-side rendering by default, which has a huge impact for the performance of the transfer-to-framebuffer phase. QPA with linuxfb doesn't have any of that. You can disable it when configuring Qt, but there's no documented option, you have to pass -D flags manually. If you're doing it, then yes you get similar display performance between QWS and QPA. But by default QPA wins. The only thing QWS buys you is built-in (and ugly) window decorations, as well as multi-process support. For everything else it's just a legacy framework with lots of overhead and a constant source of performance problems imho. In Qt 5, QPA is more complete and works on the desktop systems. Does Qt5-QPA on non-OpenGL hardware perform not worse than Qt4.8-QWS? Of course. Performance has nothing to do with it, since in your case everything will be running software rendering anyway. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Qt Embedded
Very useful, thanks a lot for taking the time to write those down! Romain On Friday, June 22, 2012 07:45:19 AM Girish Ramakrishnan wrote: Hi, For those who were unable to attend, I have posted notes on http://qt-project.org/groups/qt-contributors-summit-2012/wiki/Qt-in-Embedded . Let me know about comments Girish ___ 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] QtCS: Qt Embedded
Some comments on the notes in the wiki: * eglfs now depends on evdev. Future task is to make it compile when evdev is absent but we are yet to see such a device (qnx?) Yes, we have that exact issue with Qt5 builds for QNX on BeagleBoard. Currently we disable eglfs and use another platform plugin instead, but there should be some proper #ifdef QT_HAVE_EVDEV blocks in there. I expect the same issue on other non-linux unix embedded OSes like VxWorks, Integrity, Nucleus... KDAB can volunteer for that one (either me or one of the guys working on QNX) * cursor support hw accel on the pi, the cursor is a separate layer cool, will try to enable that on OMAP too * on the pi, each window is a layer. poor man?s wayland Awesome. Same comment as above, I'll try to add that to OMAP as well. * linuxfb needs to be resurrected +10 :) I've just been thinking about that lately, now that QtQuick2 and QtWidgets can live in parallel after all. Seems silly to have to render QtWidget based UIs with EGLFS, which yields lower quality and often lower performance results. I'm volunteering to get that going. I might not be able to get it all done by myself though. One thing I'd love to add in there too is support for more advanced buffer swapping options, if the platforms support it. For example flip mode can be easily implemented on OMAP platforms. I can see this being a massive performance gain on high resolution screens. * openvg backend Interesting, especially for the i.MX boards which have a separate OpenVG accelerator (apparently not based on OpenGL like the SGX one, so likely to perform better). It wouldn't be of much use for QQ2, but would still be helpful for many GraphicsView and Widget based apps. Should be backported to Qt4 too. Cheers Romain On Friday, June 22, 2012 07:45:19 AM Girish Ramakrishnan wrote: Hi, For those who were unable to attend, I have posted notes on http://qt-project.org/groups/qt-contributors-summit-2012/wiki/Qt-in-Embedded . Let me know about comments Girish ___ 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] QtCS: Qt Embedded
On Friday, June 22, 2012 02:09:25 AM Donald Carr wrote: w00t On Fri, Jun 22, 2012 at 1:32 AM, Romain Pokrzywka romain.pokrzy...@kdab.com wrote: Some comments on the notes in the wiki: * eglfs now depends on evdev. Future task is to make it compile when evdev is absent but we are yet to see such a device (qnx?) Yes, we have that exact issue with Qt5 builds for QNX on BeagleBoard. Currently we disable eglfs and use another platform plugin instead, but there should be some proper #ifdef QT_HAVE_EVDEV blocks in there. I expect the same issue on other non-linux unix embedded OSes like VxWorks, Integrity, Nucleus... KDAB can volunteer for that one (either me or one of the guys working on QNX) Would minimalEGL not suit your needs more then? Yeah, very true. Forget my comment then. * cursor support hw accel on the pi, the cursor is a separate layer cool, will try to enable that on OMAP too Cool * on the pi, each window is a layer. poor man?s wayland Awesome. Same comment as above, I'll try to add that to OMAP as well. Wicked * linuxfb needs to be resurrected +10 :) I am planning on whacking this when I get back to Sunnyvale on Tuesday/Wed of next week. Great, let's try to sync in July when I'm back in the Bay. I've just been thinking about that lately, now that QtQuick2 and QtWidgets can live in parallel after all. Seems silly to have to render QtWidget based UIs with EGLFS, which yields lower quality and often lower performance results. amen I'm volunteering to get that going. I might not be able to get it all done by myself though. I have already started on this, although the existing code requires far more refactoring than originally intended and I downed tools. I think this would be great to get working for the beta. I really hate this Qt 4/5 division people are mentioning. There is little reason to backport to Qt 4, since there is very little Qt 4 functionality actually stripped from Qt 5 and source compatibility is largely a reality. This also makes this more interesting: https://bugs.webkit.org/show_bug.cgi?id=84532 although webkit might actually develop a hard OpenGL ES 2 requirement. (Might already have it) One thing I'd love to add in there too is support for more advanced buffer swapping options, if the platforms support it. For example flip mode can be easily implemented on OMAP platforms. I can see this being a massive performance gain on high resolution screens. Cool, I will try to simply map the existing QPA usage to the Qt 5 QPA design. * openvg backend Interesting, especially for the i.MX boards which have a separate OpenVG accelerator (apparently not based on OpenGL like the SGX one, so likely to perform better). The Raspberry Pi is also meant to have a discrete (and apparently meaty) OpenVG processor that is currently lying dormant. Ah, even more interesting then, indeed It wouldn't be of much use for QQ2, but would still be helpful for many GraphicsView and Widget based apps. The extent to which this could be used is still a point of research as far as I am concerned. Should be backported to Qt4 too. This I disagree on. hmm, probably because it's not trivial to backport, and since Qt5 isn't that much of a departure from Qt4 after all. Agreed in second thought. Cheers Romain Cheers, Donald On Friday, June 22, 2012 07:45:19 AM Girish Ramakrishnan wrote: Hi, For those who were unable to attend, I have posted notes on http://qt-project.org/groups/qt-contributors-summit-2012/wiki/Qt-in-Embed ded . Let me know about comments Girish ___ 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
