Tag Archives: Qt Quick

OpenGL in Qt 5.1 – Part 3

This article continues our series on what is new in Qt 5.1 with respect to OpenGL. If you haven’t already seen them, you may be interested in reading Part 1 and Part 2.

Timer Queries

OpenGL on the desktop exposes a very useful tool in the shape of timer query objects. These can be used to record the amount of time taken by the GPU to process sequences of commands. If we couple this with the usual CPU profiling techniques then we can get a very complete understanding of the bottlenecks in our rendering code.

One obvious place that could take advantage of this is the Qt Quick 2 renderer. Although the Qt Quick 2 renderer does have options to enable timings of various stages of rendering, this only tells us half of the story. Namely, the CPU half. Using OpenGL timer queries would allow us to fill in the gap and gain an understanding of how the GPU is performing.

Another common use for OpenGL timer queries is to provide feedback to adaptive rendering routines in order to maintain more consistent frame rates. For example, if we instrument our rendering function and find at runtime that our application is rendering too slowly, we can perhaps increase the frame rate by using less complex shaders or by using lower resolution meshes etc. Conversely, if we find that we have GPU cycles to spare then we could improve rendering quality by perhaps using higher levels of tessellation.

Qt 5.1 will make such tasks much easier with the introduction of two new classes developed by KDAB engineers: QOpenGLTimerQuery and QOpenGLTimeMonitor. The QOpenGLTimerQuery class is a simple wrapper around a single OpenGL timer query object and can be used if you wish to have total control. It is expected that QOpenGLTimeMonitor will be the more commonly used class as this is a wrapper around a sequence of timer query objects and makes it trivial to measure the GPU time of the various stages of our rendering functions:

void Scene::initialize()
{
    // Create a timer query object
    m_timeMonitor = new QOpenGLTimeMonitor( this );
    m_timeMonitor->setSampleCount( 5 );
    if ( !m_timeMonitor->create() )
        qWarning() << "Failed to create timer query object";

    // Generate some names for the various stages of rendering
    m_renderStages << "Clear Buffer" << "VAO Binding"
                   << "Shader Program Binding" << "Drawing";
}

void Scene::render()
{
    // Start the timer query
    m_timeMonitor->recordSample();

    // Do some rendering
    m_funcs->glClear( GL_COLOR_BUFFER_BIT );
    m_timeMonitor->recordSample();
    m_vao.bind();
    m_timeMonitor->recordSample();
    m_shaderProgram.bind();
    m_timeMonitor->recordSample();
    m_funcs->glDrawArrays( GL_TRIANGLES, 0, 3 );

    // End the timer query
    m_timeMonitor->recordSample();

     ...read more 
Source: FULL ARTICLE at Planet KDE

OpenGL in Qt 5.1 – Part 1

:)

This blog is the first in a series that will show how to use OpenGL with Qt 5. In this article, we shall take a very quick look at Qt’s historical support for OpenGL and then go on to describe the first batch of new features coming in Qt 5.1 that will enhance Qt’s OpenGL support. Upcoming blogs in this series will describe more features and show some simple examples of how easy it is to use Qt for OpenGL development.

A (very) brief history of Qt and OpenGL

Qt has a long history of supporting drawing with OpenGL. Most Qt developers are aware of QGLWidget and maybe the various incarnations of the OpenGL-based paint engines. These allow drawing with raw OpenGL or with the convenience of the QPainter API respectively. In addition to these, Qt also offers some helpful wrappers around other OpenGL object types such as QGLShaderProgram, QGLFramebufferObject, QGLBuffer etc.

During the design of Qt 5, these QGL* classes were marked as “Done” and shiny new QOpenGL* replacements were introduced and placed directly into the QtGui library. The reason for these changes is that the new Qt Quick 2 renderer is based upon OpenGL and so is now a core part of Qt’s graphical offerings. Also, the new QOpenGL* classes can be used as direct replacements for the older QGL* classes. For new code, the QOpenGL* classes from QtGui are recommended.

Qt 5.0 exposed basically the same subset of OpenGL functionality as Qt 4.8 did, which is pretty much the intersection of OpenGL 2 and OpenGL ES 2. This also happens to be the functionality needed by Qt Quick 2. In addition to the Qt 4.8 functionality, Qt 5.0 also makes it very easy to create native windows and OpenGL contexts on any platform. No more messing around with the idiosyncrasies of various platforms to create a context that can support the OpenGL Core profile. Just use QOpenGLContext and save yourself from some grey hairs!

With Qt 5.1, we are beginning the adventure of exposing more and more OpenGL functionality so as to make using OpenGL with Qt simple, elegant and hopefully fun! To this end, KDAB has invested significant resources into pushing the boundaries with Qt and OpenGL.

Functions, functions everywhere!

OpenGL is, to put it bluntly, a bit of a pain to work with on some platforms. One of the major reasons for this pain is the need to resolve entry point addresses dynamically at runtime rather than the build time linker being able to do so. For example, onMicrosoftWindows, the address of any function introduced since OpenGL 1.1 must be resolved at run-time. That is nearly all of functions used in a modern OpenGL application!

To assist with this Qt has provided a couple of helpful utilities: QOpenGLContext::getProcAddress() and QOpenGLFunctions. The former can be used to perform manual resolution of entry points, whilst the latter is a class that has member functions mapping to the common subset of functions in OpenGL 2 and OpenGL ES 2. …read more
Source: FULL ARTICLE at Planet KDE

Fruits of CSS2013

Putting unexpected visions of space tourists aside, now for something completely different. This was a busy weekend with Calligra Suite Sprint 2013 which despite of different timezone fully dominated Essen and Bangalore. More about that here, here, here, here, here and here. You can find the full agenda on the KDE Community Wiki.

Lords of the ring like me were able to join at least remotely through various media. So here’s a list of my limited activities.

A Mockup for Calligra Words Look & Feel Rework

The Modern GUI and Startup screen is already established in Kexi, people know it and use saving many mouse clicks. I took some time to present a follow up, mockup of how Calligra Words word processor would look. The topic was iterated before at the previous sprint.

Calligra Words before:

Calligra Words after:

You can read about the story behind the look and inspirations that can influence what I’ll try to do. Obviously thanks to the Qt Quick taking over the overall GUI concepts, our users can expect the apps can be run will pleasure. Yes, it’s time for the desktop.

Calligra Mail Merge

The Kexi virtual BoF turned out to be an IRC meeting between me and Smit Patel, a Calligra dev who is successfully collaborating with me already on the Bibliographic Database project for Calligra Words. It takes advantage of rather awesome desktop database capabilities that Kexi offers to other apps.

This time we covered fully fledged Mail merge for Calligra, an initiative that was planned long ago. It should be as easy as possible (no tinkering with database/data source as in LibreOffice) and visible in Words with some optional visibility in Kexi for premium integration. Like the Bibliographic Database, Mail Merge reuses certain features of Kexi so that provokes my attention. More on the Mail Merge Design wiki page.

Finally a small announcement about interesting opportunity: Karbon, Plan and Braindump apps from Calligra are looking for new Maintainers. That’s rare opportunity for you!

…read more
Source: FULL ARTICLE at Planet KDE

Andrea Grandi: Using QtCreator to deploy and run a Qt application to a remote Linux device

QtCreator is a very flexible IDE and can really be adapted for a lot of things. I usually use it to develop mobile applications for Nokia N9 and BlackBerry 10, but it can be used for more generic tasks. In my case I wanted to be able to develop a Qt application using my desktop PC, deploy it and run on a remote (actually it’s on the same desk) Linux machine running Xubuntu.

Doing this is quite easy and you don’t need any specific plugin on QtCreator, but be sure to have at least version 2.6.x. Other than QtCreator you also need two Linux based PC (I used Ubuntu 12.10 for my development machine and Xubuntu 12.10 for the remote netbook) and an SSH account on the remote PC.

Add the remote device to QtCreator

QtCreatorDevice

To add the remote Linux device on QtCreator, use the Tools->Options menu and click on “Devices” item. At this point click on “Add” button and fill the fields using values similar to the screenshot. In particular specify a name for the device, the IP of the remote machine and a username and password that must already exist (I just created the user “andrea” on the Xubuntu machine and used the same password). I also had to set the timeout to 20 seconds, because I had some connection problems and the connection kept dropping after 10 seconds trying. To verify if everything is working fine, just click on Test button.

Add a specific Qt version

QtCreatorQtVersion

To write your application you may need a specific Qt version that is different from the one distributed by your Linux distribution. There’s no problem, QtCreator let you add different Qt versions without any conflict. In my case I installed the Qt5 version distributed by Canonical Qt5 Edgers Teamhttps://launchpad.net/~canonical-qt5-edgers
Once it’s installed, just click on “Add” button and select the qmake specific to the version you want to add (in my case it was in /opt/qt5/bin/qmake ).

Add a Qt Kit

QtCreatorQtKits

QtCreator permits to add new Kit (development configurations) and these kits are used during project creation to specify what you want to target. In my example I added a new kit choosing an appropriate name “Qt5 Ubuntu”, the device type, the actual device previously configured and finally the Qt version that we added before. With a kit I have a complete “toolchain” that allow me to write applications for a particular device, with a specific Qt version.

Putting the pieces together

At this point you just have to create a new “Qt Quick 2” application, and select the new kit you just created instead of the “Desktop” one. Please note that there is a little problem that I haven’t fixed yet (but I’m working on it): if you create, for example, a project named “QtTest1” it will be deployed to the folder /opt/QtTest1/ on the remote machine. By default your user doesn’t have read+write permissions for that folder so I manualy created the folder and I gave a chmod 777 on it, just for testing. There are two possible ways to fix this: you could create a specific user that has read+write permissions on /opt/ or you could modify the deployment configuration to have the app deployed to the user /home (I will investigate on this possibility and I will write something in one of the next posts).

Final thoughts

What all of this could be useful for? Well, do 2+2 and you’ll easily guess ;) In the next weeks I will post more specific informations and I will update everyone with my progresses. Any comment is welcome! If you want to contribute to this you’re welcome too of course.

Source: FULL ARTICLE at Planet Ubuntu

Krita Sketch is: Colourful

A quick recap of the main topic: My employer, KO GmbH, has been working on a touch version of Krita, called Krita Sketch, over the last few months, and has finally made the first release! So, i’m doing a bit of writing, talking about some of the work i’ve been doing as a part of this project. (you should also read the dot article, because it’s good and has shiny 😉 )In the previous instalment i wrote about rounded corners, and mentioned there was something else in Krita Sketch which was round. Those who use Krita will have already encountered the colour wheel that’s used to select colours in the application, and this is a very popular feature with the target audience, so of course we need it in Krita Sketch as well. This entry discusses the implementation of that elementAn important point to be made here is that this will not be possible in Qt 5 (which is now finally out of the door, putting to shame all the snarky predictions of postponings great work people!), and as such this point will need to be revisited once that comes around. However, as with all such things, there was a deadline so some shortcuts had to be made. This was one of those places where we felt it was more prudent to get it working right away, and then make it “correctly” later on. If you run into a similar situation, this will show you how. If you want to do it “the right way”, there’s comments on the topic here (you can still use the QQuickPaintedItem, but it is not recommended due to its inherent speed penalties – but if you have time constraints on your project, it’s a straight forward way to reuse your existing work).So, what we are talking about here is, of course, the colour selector item that you see a screenshot of above as it looks inside Krita Sketch. Under here you can see what it looks like inside Krita Desktop.What you can see here is that there is, for all practical intentes and purposes, no difference between the two. The way this was done was, quite simply, to reuse the painting code from the widget without change.Inside the declarative item there are a couple of bits of code which were unfortunately copied over from the widget version, but the code is reasonably small, so it’s not all that much of an issue, to be fair. The code is based around the idea that you have two colour selection parts, the main part, and the sub part. For now we have only got a triangle with a circle around it, but we will be introducing the same modes as found in the desktop version at a later point in time (the code is already there, it simply is not exposed in the user interface yet). This means the paint method is really quite simple: Since the sub-parts already know how to paint themselves using QPainter, we can simply tell them to be painted in the area we have available.Mouse events are handled very simply and similarly as well (just continue scrolling in that code there 😉 ). First, on mouse down, we check whether we’re handling foreground or background colours (left or right mouse button), and then we ask the main and sub components which of the two, if any, wants the input. When you then move the mouse, that component is passed the data, and that means you don’t accidentally get something picked up elsewhere. As you drag the mouse around on the component, the colour is set, and Calligra’s resource system is asked to handle this.So, very simple approach as you can tell, but one which really does work, and provided some decidedly pleasant and rapid development.To recap, if you are developing something from new, use the scene graph based drawing methods in Qt Quick 2, but if you have some existing code, you can use this method to produce a nice level of code reuse.The word of the day is: Reusable
Source: Planet KDE