Qt 5

Today we released a new unified online installer for commercial and open-source versions. Previously, we have had  separate installers for each version. Now Qt Account is used for validating the Qt license and determining if a commercial  or ... [More] open-source version should be installed. Unification of Qt systems has been ongoing for a while and we have now reached a major milestone with the unified online installer. We no longer have two separate online installers to create, test and release. Also, it is now easier to migrate from open-source to commercial license of Qt. The Qt repositories and delivery networks for commercial and open-source content are still separate, so that users with a commercial license of Qt will have access to their commercial delivery system and the additional content their license grants them access to. Users without a commercial license will be able to install the open-source version of Qt from the open-source delivery system. If you already have a Qt Account, enter your credentials when asked: If you do not yet have a Qt Account, you can create it conveniently from the online installer: When you enter your Qt Account credentials, the installer will check if there is a valid commercial license associated with your Qt Account, and you will be taken through to commercial installation. If there is no commercial license associated with your Qt Account, installation will provide the open-source version of Qt. If you do not have a Qt Account yet, you can simply create one directly via the installer. Just enter your email (this is address to which your account activation email will be immediately sent upon account creation) and the password you wish to use for Qt Account access and proceed to install. Be sure to activate your Qt Account as instructed in the email. You may also create a new Qt Account at qt.io, if you prefer. In addition to being the place to manage support tickets and downloads for commercial license holders of Qt, Qt Account credentials are used for signing in to the Qt Wiki and Forum. We are also working hard to extend the use of Qt Account for sign in to other systems, such as bugreports.qt.io. To see a list of benefits of the Qt Account, please visit our Qt Account Benefits page. The unified online installer is built with the brand new 2.0 version of the installer framework. We have worked hard to iron out all possible glitches of the installer, but in case you have problems with it, please file a bug to bugreports.qt.io. Offline installers are unchanged and still use the older version of installer framework. If you are already using a Qt online installer, you will be provided the new unified installer when using the maintenance tool. You will need to update the installer (maintenance tool), before you download other items. If you do not yet have an online installer for Qt, you can get it from the qt.io Download page or from the Qt Account portal. The post New Unified Qt Online Installer Available appeared first on Qt Blog. [Less]

We have now officially opened the Call for Papers for Qt World Summit. The Qt World Summit is the global event for all things Qt. Here, whether you are a tech strategist or a developer (even both for that matter), you can meet like-minded peers for ... [More] networking and discussions, as well as learning about creating exceptional applications and devices that your users love. We plan to build the summit around these big themes: Internet of Things systems and creating connected devices Qt as the software solution for multi-platform development – desktop, mobile and embedded The modern C++ standards and benefits Automotive and industrial HMI trends Creation of modern desktop user interfaces Enterprise multi-screen development strategies High-end UX on low-power embedded devices The Qt World Summit will consist of two inspiring and educational days starting with keynotes from the creators of Qt and top industry leaders who will share their experiences with Qt. After being updated on the Qt roadmap, we will offer you a variety of sessions covering everything from technology strategy and product lifecycle management to in-depth technical talks on new APIs, best practices and live coding sessions all presented by Qt contributors and industry experts from around the world. In the call for papers you will find three main talk categories: Qt Technology Strategy, Qt Application Development and Device Creation, and Seeking Innovation. More details to be found here. We invite all of you, from within the Qt community and the related industries, to submit your suggestions and abstracts. We are looking forward to your contribution and together make the best Qt event to date. Download the guidelines. The conference also wouldn’t be nearly as amazing without our sponsors. We are very happy to have KDAB as our Diamond sponsor, showing their strong and continued commitment to the Qt ecosystem especially after their great effort of organizing the previous Qt Developer Days. A huge thanks also to e-GITS and Froglogic as Gold sponsors, and basysKom as Silver sponsor. We also welcome more support so if you are considering sponsoring to get your message out to an amazing audience, please review the Sponsor Prospectus. The post Experts Wanted: Call for Papers | Qt World Summit 2015 appeared first on Qt Blog. [Less]

Exciting times are ahead for the Microsoft Windows platform, so we want provide you with an update on our plans. Windows 10 is approaching and there is a large amount of improvements coming with Qt 5.5, making the WinRT / Windows Store Applications ... [More] support better. With this improvements, we would also like to announce that starting with Qt 5.5 we will offer the Qt port of WinRT/Windows Store Applications under the LGPLv3/GPLv2+/Commercial licenses. Windows 10 Provides Compatibility with Existing Qt Applications Microsoft has indicated that they are planning to release Windows 10 this summer, so many Qt users have been curious about the support level we are aiming to provide with Qt 5.5 and subsequent releases. The good news is that all Qt applications created with earlier Windows versions will run on Windows 10 without any limitation. That includes classic desktop (Win32) applications as well as Windows Store Applications (WinRT). One thing to mention is that on Windows 10 also the Windows Store Applications will be windowed and not only in full-screen anymore. This is supported already if you have an application in the Windows Store and Qt 5.5 will provide further improvements to smoothen glitches on resizing. Qt Offers Portability from Win32 to WinRT The new API for Windows Store Applications (WinRT) is very different from the Win32 API used by the classic Windows applications. Therefore, a developer who has created a native Windows application needs to in essence re-create the application to use the new API for Windows Store Applications. Fortunately, the situation is much better with Qt-based Windows applications. For any application which uses just the functionality provided by Qt, the only required step is to recompile your Qt for Windows application with WinRT port of Qt to make it a Qt for Windows Store Application. If your application uses native Win32, some further work is needed, but the Qt parts are really easy. Unfortunately, the automatic styling functionality is not available for the WinRT port of Qt, so although both widgets and Qt Quick work well, the application does not automatically get the platform style. Improvements to the Qt for WinRT (Windows Store Applications) Microsoft’s new API for Windows Store Applications is available in PCs, tablets, phones, and later on, also on embedded devices. A great value is that the same application can run across a wide variety of devices, and all the different kinds of devices can access the common store for applications. Qt applications have been available for earlier versions of both Windows Phone and WinRT for a while now, and we can leverage the same baseline for Qt 5.5 and Windows 10 support. For Qt 5.5 we have put a lot of effort into further stabilizing and improving the quality of our existing Qt for WinRT port, which supports all variances of Windows Store Apps (desktop and phone). We have been going through the feedback from previous releases and addressed all the most requested items. Qt 5.5 greatly improves, for example, Multimedia support and Visual Studio integration/deployment. Support for Visual Studio 2015 So far Qt for WinRT applications have been built with Visual Studio 2013, which continues to work with Windows 10. There is also a new compiler coming later this year in Visual Studio 2015, which is a major update on the development environment. Visual Studio 2015 Community Technology Preview (CTP) has been out for a while, so we have been doing some research on how Qt behaves against that and some commits are already in the 5.5 branch, while others are still a work-in-progress. Visual Studio 2015 is still under heavy development, so there are currently some workarounds needed to build Qt with it. After the final version is out, we intend to provide support for it in a Qt 5.5.x patch-level release, including pre-built binaries. Furthermore, the first preview of the Windows 10 SDK has been released, which is valid for Windows Store Apps, including Windows 10 Mobile. We are able to compile Qt against that SDK as well, with a couple of changes required. Similarly as for Visual Studio 2015, we are planning to fully support Windows 10 SDK, after it is officially released. Use of LGPLv3/GPLv2+/Commercial License With Qt 5.5 we are changing the license of the Qt for WinRT port to be LGPLv3 / GPLv2+ / commercial license. We believe that LGPLv3 is a better and clearer license than the older LGPLv2.1, so we want to use it for WinRT / Windows Store Applications in Windows 10 (as well as Windows 8.1 and Windows Phone 8.1). The open-source licenses LGPLv3 and GPLv2+, as well as the commercial licenses of Qt, are compatible with Microsoft’s terms and conditions for the Windows Store. To learn more why we want to use LGPLv3 in Qt and what it means, please check the blog post about introducing LGPLv3 license option and qt.io licensing pages. Full Support for Windows 10 Coming with Qt 5.5.x As Qt 5.5.0 is scheduled to be released before Windows 10, we aim to provide full support for Windows 10 with a Qt 5.5.x patch release after Windows 10 is available. Our intention is to provide initial support for Windows 10 already with the Qt 5.5.0 release, so that users can try out Qt on Windows 10 preview versions. As also the Qt applications created with earlier Windows versions will run nicely in Windows 10, we see that things are in good shape for the upcoming major new Windows release. The post Windows 10 Support in Qt appeared first on Qt Blog. [Less]

We are happy to announce the release of qbs 1.4.0 today. What’s new? In addition to lots of bugfixes and smaller improvements, this release also brings a number of new features: With the new builtByDefault property, it is now possible to specify ... [More] that a product should not be built unless that is explicitly requested. One useful application of this feature is the new item AutotestRunner, which provides functionality similar to “make check”. Files are now by default installed as part of the build process, in order to allow products that work on the contents of the installation directory (see the item below). There is now an archiver module, which we use to implement the InstallPackage item. We have added experimental Android support, for projects with or without native code. Note that there is no special support for Qt yet, and Qt Creator integration is also missing. Try it! Source packages and a binary package for windows can be downloaded here. Other relevant links Wiki: http://qt.io/wiki/qbs Documentation: http://qt.io/doc/qbs/index.html Bug tracker: https://bugreports.qt.io/browse/QBS Mailing list: http://lists.qt-project.org/mailman/listinfo/qbs The post qbs 1.4.0 released appeared first on Qt Blog. [Less]

We are happy to announce Qt Japan Summit in Akihabara on Tuesday, May 26 this year. Join us! Tokyo, Japan: May 26 Last year’s Qt Developer Day Tokyo was a successful event with 300+ attendees joining a full day of technical tracks focused on ... [More] embedded, desktop, mobile and multi-screen development. With a clear growing interest in Qt, we will return this year to keep the Qt momentum going in Japan and interact with businesses, Qt lovers, supporters and new Qt users. Japan has been a friend of Qt and champion for the past several years where leading companies in automotive, consumer electronics, robotics & automation have standardized on Qt. We continue to find a bustle of energy from the local community and are grateful for the support. We are excited to position Qt Japan Summit as a part of the Qt World Summit happening later this year where our aim is to continue supporting the Qt Japan ecosystem. The agenda & registration for the Qt Japan Summit is already available, and we recommend that you stay tuned to our channels including Qt.io/qtjapansummit and the twitter hashtag #QtJS. The post Qt Japan Summit 2015 appeared first on Qt Blog. [Less]

We are happy to announce the release of Qt Creator 3.4.0 today. I’m highlighting some of the many new features below. Please take a look at our change log for a more complete list of features and fixes. The C++ support in Qt Creator now has a new ... [More] refactoring action that moves all function definitions out of a class declaration. We also added auto-completion for signals and slots in Qt 5 style connects. Just type the “&” and let auto-completion figure out the type of the object. Also new is a locator filter, All Included C/C++ Files, which finds all files that are used in your project by including them, even if they are not explicitly mentioned in your project. The filter is part of the default that is used when you just type in the Locator input field, and shares the shortcut string with Files in Any Project. For users of the Professional or Enterprise edition we added experimental integration for Qt Test based auto tests and Qt Quick tests. It adds another navigation pane Tests, which lists the tests defined in your project, provides ways to run individual or sets of tests, and nicely shows test results in a new Test Results output pane. To try it, open Help > About Plugins (Qt Creator > About Plugins, on OS X), turn on Utilities > AutoTest, and restart Qt Creator. We also moved the Clang static analyzer integration out of experimental state. If you have at least Clang 3.6 installed, it now also supports using it with MSVC and MinGW. We also added suppression of individual diagnostics for a file, and a new page in Projects mode for managing these. Other new features include Changing the environment for running external tools Searching through QML Profiler event notes Using 64bit Android tool chains Using generic projects for bare metal development Highlighting of parenthesis in generic highlighters See the change log for more. You find the opensource version on the Qt download page, and Enterprise packages on the Qt Account Portal. Please post issues in our bug tracker. You also can find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list. The post Qt Creator 3.4.0 released appeared first on Qt Blog. [Less]

Hello! This is a friendly reminder that the Qt Contributors’ Summit is coming soon. June is only a month and a half away and Spring is well on it’s way in Oslo. We will be gathering in Oslo, starting with an unofficial pre-event on the 5th June and ... [More] the Summit on the weekend of 6th – 7th. If you are coming, please register by the end of this month with the registration form. For those of you not familiar with the Qt Contributors’ Summit, it is a two day event for people contributing to the Qt project in some way. We gather to discuss the current state and future of the project. Everyone who shares our passion for Qt is welcome. The wiki pages for the event are now online too. For those of you coming, the Program page is especially important, as the event format is an unconference. This means that the attendees can, and should, reserve slots for discussions and presentations in the event. I would also like to thank all the companies that are making the Summit possible: The Qt Company, Boundary Devices, Intel, ICS, e-Gits, Froglogic, Pelagicore and KDAB. Thank you for helping make Qt Contributors’ Summit special this year! See you in Oslo! The post Qt Contributors’ Summit is coming closer appeared first on Qt Blog. [Less]

QMetaType is Qt's way to have run-time dynamic information about your types. It enables things such as QVariant wrapping of custom types, copy of queued connection arguments, and more. If you ever wondered what does Q_DECLARE_META_TYPE or ... [More] qRegisterMetaType do and when to use (or not to use) them, read on. This article will describe what you need to know about QMetaType: What is its purpose; How to use it; And how it works. Why does Qt need runtime dynamic type information? Let's start with a bit of history. QMetaType was introduced in Qt 4.0. It was created in order to have the possibility to have asynchronous signals and slots (Qt::QueuedConnection). For queued slots to work, we have to copy the arguments and store them in an event that will be processed later. We also need to delete those copies when we are finished invoking the slot. (Note: This is not needed when using Qt::DirectConnection: pointers to arguments directly on the stack are used.) The code dispatching signals in QMetaObject::activate has an array of pointers to arguments void*. (For more info read how signals and slots work). But, at the time, all Qt knows about the argument types are their name as a string, extracted by moc. QMetaType provides a way from the string (e.g. "QPoint") to get a to copy or destroy the object. Qt would then use void *QMetaType::create(int type, void *copy) and QMetaType::destroy(int type, void *data) to copy and destroy the arguments, where the int type is obtained using QMetaType::type(const char *typeName) using the type name of the argument, as provided by moc. QMetaType also provides a way for the developer to register any kind of type in the meta type database. Another use case for QMetaType is QVariant. The QVariant from Qt 3.x only supported built-in Qt types because a contained arbitrary type would also need to be copied or destroyed together with the wrapping QVariant. But with the help of QMetaType, QVariant was able to contain any registered type since QVariant can now copy and destroy contained instances of objects. What information does QMetaType keep? Since Qt 4.0 a lot has changed. We now have QtScript and QML which are making intensive use of the dynamic type integration. And we had to optimize a lot. Here is the list of information kept for each type in the meta-type system: The Type Name as registered. There is a name index for fast lookup of the meta type id. Since Qt 4.7, it is even possible to register the same type with different names (useful for typedefs). (Copy) Constructor and Destructor (in-place or not). Size to know how much space to allocate for a stack or inline member construction. Flags specifying the same information as QTypeInfo (see bellow) or the type of conversion. Custom conversion functions, set by QMetaType::registerConverter. QMetaObject, containing the meta QObject data associated with a type if it exists. … QTypeInfo QTypeInfo is a trait class orthogonal to QMetaType, it allows the developer to manually specify (using the Q_DECLARE_TYPEINFO) that a type is movable (using memmove) or if its constructor/destructor need to be run. This is mainly used for optimization in containers like QVector. For example, the implicitly shared classes may be moved with memmove. While a normal copy should first increase the reference count with the copy constructor and then decrease it in the destructor. C++11 introduces move constructors and standard type traits to solve this problem, but since QTypeInfo was designed way before C++11 and Qt still has to work with older compiler, we have to do without. How does it work? For historical reason, there is a big difference between built-in types and custom types. For built-ins types in QtCore, each meta-type function is basically a switch that has special code for each type. In Qt 5.0 this was re-factored to use templates a lot. (See QMetaTypeSwitcher.) But what is going to interest us in this article is how it works for custom registered types. There is simply a QVector<QCustomTypeInfo> that holds all the information and a bunch of function pointer. The Q_DECLARE_METATYPE macro. That macro specializes the template class QMetaTypeId for the specific type. (In fact, it actually specializes the class QMetaTypeId2 and most of the code uses QMetaTypeId2. I don't know the exact reason behind QMetaTypeId2. Maybe so that Qt can add more built-in types without breaking code that used Q_DECLARE_METATYPE before.) QMetaTypeId is used to determine the meta-type id at compile time for a type. QMetaTypeId::qt_metatype_id is the function called by the qMetaType(). On the first call of this function, it will call to some internal function within QMetaType to register and allocate a meta-type id for this type, using the name specified in the macro. It will then store that id in a static variable. Apart from the name, all other information is automatically inferred by the compiler using templates. qRegisterMetaType Type registered using Q_DECLARE_METATYPE are going to be actually registered (and be assigned an id) on the first use of qMetaTypeId(). That's the case when a type is wrapped in a QVariant for example. But this is not yet registered when connecting signals and slots. In that case you need to force the first use using qRegisterMetaType Automatic registration. Developers often forget to register their meta-type until they see the compilation error or run-time error telling them to do so. But wouldn't it be nice if it would not be necessary? The only reason Q_DECLARE_METATYPE is necessary is to get the name. But there are cases where we can know the name at run-time without that macro. For example, QList if T is already registered, we can query the meta-type system and construct the name using "QList<" + QMetaType::name(qMetaTypeId()) + ">" We do that for a bunch of templated classes, for example: QList, QVector, QSharedPointer, QPointer, QMap, QHash, ... We can also determine the name of a pointer to a QObject subclass thanks to the information provided by moc: T::staticMetaObject.className() + "*" And from Qt 5.5, we will also automatically declare the Q_GADGET and Q_ENUM. That was it for Q_DECLARE_METATYPE, but you would still need to call qRegisterMetaType to use these type in a Q_PROPERTY or as a parameter in a signal/slot queued connection. Since Qt 5.x however, the code generated by moc will call qRegisterMetaType for you if moc can determine that the type may be registered as a meta-type. Research Before Qt 5.0, I was trying to investigate if we would not be able to get rid of Q_DECLARE_METATYPE for cases in which we do not need the name. This worked somehow like this: template QMetaTypeId { static int qt_metatype_id() { static int typeId = QMetaType::registerMetaType(/*...*/); return typeId; } }; According to the C++ standard, there shall be exactly one instance of the variable QMetaTypeId::qt_metatype_id()::typeId for each type. But in practice some compilers or linkers do not obey this rule. In particular, on Windows, there would be one instance per library even when using the proper export macro. We would therefore always need a name identifier which we don't have. (And we don't want to rely on RTTI). Therefore we only register the type for which we can know the name in Qt 5. [Less]

Users find it frustrating and reluctantly accept the fact that connection to the Internet sometimes has glitches. Wait times are the norm. Users are accustomed to the cursor loading slowly, popping up periodically and at times needing to try a second or third time in order to connect to an online site.

Many Qt users encounter a need to integrate GPU compute solutions into their Qt-based applications. What is more, with the advent of compute API implementations and powerful GPUs on embedded devices, using OpenCL or CUDA on an Embedded Linux device ... [More] is a reality now. In a previous post we looked at NVIDIA’s Jetson TK1 board and discovered how easy it is to get started with CUDA development in Qt applications using OpenGL. When it comes to OpenCL, developers are not left out in the cold either, thanks to Hardkernel’s ODROID-XU3, where the ARM Mali-T628 graphics processor provides full OpenCL 1.1 support with CL-GL interop in addition to OpenGL ES 3.0. In this post we will take a look at a simple and powerful approach to integrating Qt Quick applications and OpenCL. We will focus on use cases that involve sharing OpenGL resources like textures or buffers between OpenGL and OpenCL. The examples demonstrate three standard compute use cases and we will see them running on an actual ODROID board. ODROID-XU3 Why OpenCL and Qt? The ability to perform complex, highly parallel computations on embedded devices while keeping as much data on the GPU as possible and to visualize the results with Qt Quick and touch-friendly Qt Quick Controls open the door for easily creating embedded systems performing advanced tasks in the domain of computer vision, robotics, image and signal processing, bioinformatics, and all sorts of heavyweight data crunching. As an example, think of gesture recognition: with high resolution webcams, Qt Multimedia, Qt Quick, Qt Quick Controls, and the little framework presented below, applications can focus on the things that matter: the algorithms (OpenCL kernels) performing the core of the work and the C++ counterpart that enqueues these kernels. The rest is taken care of by Qt. Looking back: Qt OpenCL OpenCL is not unknown to Qt – once upon a time, back in the Qt 4 days, there used to be a Qt OpenCL module, a research project developed in Brisbane. It used to contain a full 1:1 API wrapper for OpenCL 1.0 and 1.1, and some very helpful classes to get started with CL-GL interop. Today, with the rapid evolution of the OpenCL API, the availability of an official C++ wrapper, and the upcoming tighter C++ integration approaches like SYCL, we belive there is little need for straightforward Qt-ish wrappers. Applications are encouraged to use the OpenCL C or C++ APIs as they see fit. However, when it comes to the helpers that simplify common tasks like choosing an OpenCL platform and device so that we get interoperability with OpenGL, they turn out to be really handy. Especially when writing cross-platform applications. Case in point: Qt Multimedia 5.5 ships with an OpenCL-based example as presented in the video filters introduction post. The OpenCL initialization boilerplate code in that example is unexpectedly huge. This shows that the need for modern, Qt 5 based equivalents of the old Qt OpenCL classes like QCLContextGL has not gone away. In fact, with the ubiquity of OpenCL and OpenGL on all kinds of devices and platforms, they are more desirable than ever. Qt 5.5 on the ODROID-XU3 Qt 5.5 introduces support for the board in the device makespec linux-odroid-xu3-g++. Just pass -device odroid-xu3 to configure. For example, to build release mode binaries with a toolchain borrowed from the Raspberry Pi, assuming a sysroot at ~/odroid/sysroot: ./configure -release -prefix /usr/local -extprefix ~/odroid/sysroot/usr/local -hostprefix ~/odroid/qt5-build -device odroid-xu3 -device-option CROSS_COMPILE=~/odroid/toolchain/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf- -sysroot ~/odroid/sysroot -nomake examples -nomake tests -opengl es2 This will configure the Qt libraries and target tools like qmlscene to be deployed under /usr/local in the sysroot, while the host tools – like the x86 build of qmake that is to be used when building applications afterwards – get installed into ~/odroid/qt5-build. When it comes to the platform plugins, both xcb and eglfs are usable, but only one at a time: the Mali graphics driver binary is different for X11 and fbdev, and has to be switched accordingly. The Ubuntu image from Hardkernel comes with X11 in place. While OpenGL is usable under X too, the usage of eglfs and the fbdev drivers is recommended, as usual. For more information on the intricacies and a step by step guide to deploying Qt on top of the Hardkernel image, see this wiki page. It is worth noting that thanks to Qt’s Android port, running a full Android system with Qt apps on top is also feasible on this board. Time for some action Now to the fun part. Below are three examples running on the framebuffer in full HD resolution with the fbdev Mali driver variant, Qt 5.5 and the eglfs platform plugin. All of them utilize OpenCL 1.1, CL-GL interop, and are regular Qt Quick 2 applications. They all utilize the little example framework which we call Qt Quick CL for now. OpenGL texture to OpenGL texture via OpenCL An OpenCL-based alternative for ShaderEffect First, let’s take a look at a standard image processing use case: we will execute one or more OpenCL kernels on our input, which can be a Qt Quick Image element, a (potentially invisible) sub-tree of the scene, or any texture provider, and generate a new texture. With CL-GL interop the data never leaves the GPU: no pixel data is copied between the CPU and the GPU. Those familiar with Qt Quick have likely realized already that this is in fact an OpenCL-based alternative to the built-in, GLSL-based ShaderEffect items. By using the easy-to-use base classes to automatically and transparently manage OpenCL and CL-GL initialization, and to hide the struggles and gotchas of Qt Quick’s dedicated render thread and OpenGL contexts, the meat of the above application gets reduced to something like the following: class CLRunnable : public QQuickCLImageRunnable { public: CLRunnable(QQuickCLItem *item) : QQuickCLImageRunnable(item) { m_clProgram = item->buildProgramFromFile(":/kernels.cl"); m_clKernel = clCreateKernel(m_clProgram, "Emboss", 0); } ~CLRunnable() { clReleaseKernel(m_clKernel); clReleaseProgram(m_clProgram); } void runKernel(cl_mem inImage, cl_mem outImage, const QSize &size) Q_DECL_OVERRIDE { clSetKernelArg(m_clKernel, 0, sizeof(cl_mem), &inImage); clSetKernelArg(m_clKernel, 1, sizeof(cl_mem), &outImage); const size_t workSize[] = { size_t(size.width()), size_t(size.height()) }; clEnqueueNDRangeKernel(commandQueue(), m_clKernel, 2, 0, workSize, 0, 0, 0, 0); } private: cl_program m_clProgram; cl_kernel m_clKernel; }; class CLItem : public QQuickCLItem { Q_OBJECT Q_PROPERTY(QQuickItem *source READ source WRITE setSource) public: CLItem() : m_source(0) { } QQuickCLRunnable *createCL() Q_DECL_OVERRIDE { return new CLRunnable(this); } QQuickItem *source() const { return m_source; } void setSource(QQuickItem *source) { m_source = source; update(); } private: QQuickItem *m_source; }; ... qmlRegisterType("quickcl.qt.io", 1, 0, "CLItem") ... import quickcl.qt.io 1.0 Item { Item { id: src layer.enabled: true ... } CLItem { id: clItem source: src ... } } Needless to say, the application works on a wide variety of platforms. Windows, OS X, Android, and Linux are all good as long as OpenGL (ES) 2.0, OpenCL 1.1 and CL-GL interop are available. Getting started with OpenCL in Qt Quick applications won’t get simpler than this. OpenGL texture to arbitrary data via OpenCL Histogram in Qt Quick directly on the GPU And now something more complex: an image histogram. Histograms are popular with Qt, and the recent improvements in Qt Multimedia introduce the possibility of efficiently calculating live video frame histograms on the GPU. In this example we take it to the next level: the input is an arbitrary live sub-tree of the Qt Quick scene, while the results of the calculation are visualized with a little Javascript and regular OpenGL-based Qt Quick elements. Those 256 bars on the right are nothing else but standard Rectangle elements. The input image never leaves the GPU, naturally. All this with a few lines of C++ and QML code. OpenGL vertex buffer generation with OpenCL VBO generation from OpenCL Last but not least, something other than GL textures and CL image objects: buffers! The position of the vertices, that get visualized with GL by drawing points, are written to the vertex buffer using OpenCL. The data is then used from GL as-is, no readbacks and copies are necessary, unlike with Qt Quick’s own GL-based particle systems. To make it all more exciting, the drawing happens inside a custom QQuickItem that functions similarly to QQuickFramebufferObject. This allows us to mix our CL-generated drawing with the rest of the scene, including Qt Quick Controls when necessary. Looking forward: Qt Quick CL QtQuickCL is a small research and demo framework for Qt 5 that enables easily creating Qt Quick items that execute OpenCL kernels and use OpenGL resources as their input or output. The functionality is intentionally minimal but powerful. All the CL-GL interop, including the selection of the correct CL platform and device, is taken care of by the module. The QQuickCLItem – QQuickCLRunnable split in the API ensures easy and safe CL and GL resource management even when Qt Quick’s threaded render loop is in use. Additional convenience is provided for the cases when the input, output or both are OpenGL textures, like for instance the first two of the three examples shown above. The code, including the three examples shown above, is all available on Gerrit and code.qt.io as a qt-labs repository. The goal is not to provide a full-blown OpenCL framework or wrapper, but rather to serve as a useful example and reference for integrating Qt Quick and OpenCL, and to help getting started with OpenCL development. Happy hacking! The post Qt Quick with the power of OpenCL on Embedded Linux devices appeared first on Qt Blog. [Less]