Qt Graphical Effects in Qt Labs

Published Thursday February 2nd, 2012 | by

Introduction

The Qt Graphical Effects project is on its way to offer a set of design neutral visual effects for Qt Quick 2.0.

Over twenty ready-made QML graphical effect elements are currently available. The effects include code for blending, masking, blurring, coloring, and much more. There are still areas to improve and extend — all ideas, feedback, proposals and even concrete contributions are welcome!

The Effects

The Effects

Using the effects

Using the graphical effect elements should be straightforward for developers and technically oriented designers as you only need to know basic Qt Quick/QML to get started.

Any QML item can be used as a source item for an effect. You can add a drop shadow to an image, for instance, as follows:

import QtQuick 2.0
import QtGraphicalEffects 1.0

Item {
    width: 300
    height: 300

    Rectangle {
        id: background
        anchors.fill: parent
    }

    Image {
        id: butterfly
        source: "images/butterfly.png"
        sourceSize: Qt.size(parent.width, parent.height)
        smooth: true
        visible: false
    }

    DropShadow {
        anchors.fill: butterfly
        horizontalOffset: 3
        verticalOffset: 3
        radius: 8.0
        samples: 16
        color: "#80000000"
        source: butterfly
    }
}

Getting started

Get and build Qt5: http://developer.qt.nokia.com/wiki/Building_Qt_5_from_Git

Make sure that qtbase/bin is in your path and QTDIR points to /qtbase

Get and build Qt Graphical Effects module: https://qt.gitorious.org/qt-labs/qtgraphicaleffects

git clone git@gitorious.org:qt-labs/qtgraphicaleffects.git
cd qtgraphicaleffects
qmake
make install

To see the effects in action, run the code examples from the graphical effects doc/src/snippets folder:

qmlscene doc/src/snippets/DropShadow-example.qml

or launch the Testbed application:

qmlscene tests/manual/testbed/testBed.qml

The Testbed application is a convenient way to browse the effects and their properties as well as to visualise the results. Select an effect from the left, adjust its properties on the right, and see the result in the center in realtime:

API and documentation

The API for each effect is a set of QML properties. The effect properties can be animated just like any other QML properties. The documention contains property descriptions and basic usage examples. To generate the documentation, execute the following commands in the qtgraphicaleffects projects folder:

qmake
make docs

Open the generated doc/html/qml-graphicaleffects-index.html in a browser to view the documentation.

documentation

Implementation details

QML ShaderEffect is a built-in element in Qt Quick 2.0. This powerful QML element allows combining OpenGL Shading Language (GLSL) and QML, and makes it easy to implement visually impressive custom effects. Under the hood, all the effects in this project are based on ShaderEffect elements. Only QML and GLSL have been used, and there are no additional C++ APIs. If you are familiar with GLSL, you can easily study how the existing effects have been implemented. You can then create custom effects by modifying and combining the basic effects.

Links to related blog posts and specifications


 

Did you like this? Share it:
Bookmark and Share

Posted in OpenGL, Qt Quick

42 comments to Qt Graphical Effects in Qt Labs

cba says:

great! but what the plan to QT5, when would version TP, beta, RC will public release?

stephane says:

Amazing O_O

Really impressive

smoggy says:

Whoaaaaaaaaaaaaaa. Very handy plugin !

Stony says:

@cba
Alpha I think I read would be out in a month or so, final release is mid-year.

nuno says:

Finlay :D masks and blur :) now I can really do some damage :D
Thank you thank you and, Thank you!!!!!

Sami Lehtonen says:

Thanks for your positive feedback!

@cba: If “approving reception” is given by the community here, we are happy to contribute this new stuff to Qt5 as an add-on module.

Saija Eteläniemi says:

I would totally vote for this becoming an add-on module to Qt5. If anyone is interested, and visiting FOSDEM this weekend, don’t hesitate to visit Open Mobile Linux devroom on Saturday 12:30 to hear a talk related to my project called “Cinnamon” (https://github.com/matrixx/Cinnamon) and some info concerning QML Shader Effects and Harmattan :)

JubiluM says:

Nice :) !

But why not implement these as inherited QGraphicsEffect – classes so that also C++ – programmers would have an access to these? Requires about the same effort whether you implement it in qml, or C++.

Would serve both C++ and qml – programmers.

peppe says:

Uhm. I already want http://www.opengtl.org/ integration. :)

Symantec says:

Please Qt Quick 2 will be available for Symbian Belle/Carla?

Ayman says:

Please Qt Quick 2 will be available for Symbian Belle/Carla?

Gil Hagi says:

Fantastic stuff. Are there any plans to unify ShaderEffectItems and the Qt/3D ShaderProgram element in some way? It would be nice if these sorts of effect collections could be reused in both modules without having to be reimplemented separately in Qt/3D.

ary says:

What do you mean by “design neutral” in this context?

Anyways, looks great.

Alexander says:

Nice.
Are these effects available from C++, or from QML only?
If they are QML-only, they are useless to me, unfortunately.
Alexander

Matti says:

I wonder why they are not called Qt Quick Graphical Effects, as they obviously are that, and not Qt Graphical Effects.

JubiluM says:

@Alexander:

Unfortunately, if you look at the sources, it’s all qml :( .

I would really like to see true mutual development of C++ and qml, side by side, within Qt. That would be strengthening of the community instead of dividing. Bonding between qml and C++ users.

Gunnar Sletta says:

JubiluM: The QGraphicsView and QGraphicsEffect architecture is fundamentally limited when it comes to hardware accelerated graphics and the effects were added as an afterthought. It does the job ok, but basing our graphical effects on this API would never have gotten us the performance we need. The new QML Scene Graph was designed to run optimal on graphics hardware and to support effects inside the rendering tree and it does do a significantly better job at it :)

JubiluM / Alexander: Even though this is QML based, using the recently introduced QSGTextureProvider API in QQuickItem, you can have your QPainter based code, even redirect a QSGPaintedItem to QWidget::render() if you can take the performance hit, and let the item be exposed as an element in QML that you can then apply effects on. You need to get your hands dirty with QML, of course, but it does integrate with C++ quite nicely.

ary: I believe the term “design neutral” comes from that these effects are generally useful, they are not there to fulfill a particular design concept. The ShaderEffect API opens up a lot different kinds of graphical effects, and although some of the things we have done are cool to look at, they are more demos and UI concepts than effects that make sense to have in a module that is generally useful to a lot of people.

Robert says:

Has the C++ side of Qt put into “bug fix and maintenance mode”? The blog entries lately certainly suggest so.

Naturally, there’s a lot of envy doing the talking here. Because I won’t be able to make use of many of the juicy features presented here – for years to come.

JanneK says:

I echo Gil Hagi’s comment. I recently started looking into integrating 3D views into QML code and currently it is brew your own or use Qt/3D module which already has links in docs leading to 404.

Could there be 3D QML item in Qt Quick 2 or is that too far off from current intent of use?

JubiluM says:

@Gunnar Sletta:

“The new QML Scene Graph was designed to run optimal on graphics hardware and to support effects inside the rendering tree and it does do a significantly better job at it ”

Understand that. But the backend is C++, basically just a convenient api for C++ – “end users” is missing. The performance and nice new features are provided through qml interface, it is not that it couldn’t be offered for C++ – users, it’s more of a decision. And you will also have to remember that there are performance issues in a scripted environment itself, when application architecture is something less trivial.

“Even though this is QML based, using the recently introduced QSGTextureProvider API in QQuickItem, you can have your QPainter based code, even redirect a QSGPaintedItem to QWidget::render() if you can take the performance hit, and let the item be exposed as an element in QML that you can then apply effects on. You need to get your hands dirty with QML, of course, but it does integrate with C++ quite nicely.”

It is really nice that it is possible…I haven’t delved into the subject deeply but know about the possibility. However, there are some issues…for example, if I use Visual Studio or Xcode…am I able to do it? And as always, involving yet another programming language into ones project, with possible issues with debugging etc., is a showstopper for some.

Cavewhere says:

Awesome! Super excited about trying this out.

S says:

@JubiluM @Robert:
I use QML in frontend and C++ in backend and I really think that it’s a really good evolution for Qt (I use Qt since 2.X). I use QML when I can, standard way if it’s not possible. For my point of view, there’s no need to have a fight between C++ and QML, that’s not the same things. It’s really easier to tweak apps with QML, and it’s easier to animate/modify things. Of course they are some issues (performance, ModelView, …) but you can still use the normal way(QWidget, QGraphicsView). Most of graphics effects is now done with shaders in GLSL (no QML, no C++), the workflow is managed by the scenegraph for QML, it’s a good thing! You can update your shader in live.
As you can see it’s possible to manage C++ AND QML, you should look at the Qt commit logs to see that there’s still C++ development.
Peace!

Jobs says:

Amazing!! How about Tilt & Shift (TS) effect ??

Mark says:

Wow! That looks very nice and exactly what i was looking for some time ago! I would like to give it a test run, but i prefer to wait for a Qt 5 version that is feature complete. Actually waiting for a Qt5 beta 1 (or rc 1) release :)

JubiluM says:

@S:
I use the mainly C++ frontend since it fits my problem space perfectly. As I’ve said, there are plenty of use cases where qml just doesn’t fit (for starters…no one hasn’t addressed the issue how to work with an IDE different from Qt Creator…Visual studio for example?). Thats why widget Qt is so popular, it is by far the best solution for making cross platform desktop programs. At the moment qml just simply does not serve desktop besides simple programs.
It is even hard and not meaningful to compare them (which is easier to modify “things”) since they naturally serve best different purposes. Like said, there is need for both.

I know it’s easy no to see beyond own needs and say an opinion that were to solve all the problems in the world…one workind with a light, mobile application has a totally different problem space than one working with a CAD application…or Scribus. And I am not saying that one problem space would be more difficult than other. They’re just different and might need different tools to tackle right.

I think that it is really important to develop both qml and widget – frontends. You find massive amount of projects, both open source and commercial, using widget/C++ frontend and you see new projects popping up all the time. No wonder, it’s the best there is for C++ programmers.

Rupert says:

@JubiluM

c++ interfaces are a binary contract we do not want to be beholden to on the performance frontier. Qt 4 was a stinker performance wise out of the box due to binary/behavior compatibility we were obligated to maintain. People have to create items, and promptly set 10 attributes to get anywhere near the potential performance on optimal hardware. Having a situation where the default path is fraught with bear traps is less than ideal. Contrast this to QML:

find . -name “*.qml” | xargs sed -i ‘s/QtQuick 1.1/QtQuick 2.0′

has proven remarkably resilient, despite the fact we have:

1) Entirely changed js engines
2) Entirely changed the graphical pipeline

QML is not for idiots, it is productive for c++ engineers and most who actually get past the political inertia appear to enjoy it. (Does QGraphicsView actually get people that wet, really?) I would like to see numbers on this (rather than my own claims) but the haters appear to fall in 2 camps:

1) Those missing desktop widgets (understandable and scheduled to be fixed with the launch of Qt 5)
2) Those who will never accept a scripting language on principle

I look at C engineers who look down on C++, and C++ engineers who look down on QML in exactly the same fashion. I would rather talk to my cat to be frank.

Kaitsu says:

Rupert: +1 from me!

More QQuick* C++ can be provided as public APIs in Qt 5.x timeframe. But right now it’s more important to find the best possible performance and feature set and deliver it on QML level.

Ayman says:

please Qt Quick 2 will be available for Symbian Belle and Symbian Carla?

muenalan says:

Great work, I like it !

@peppe: Oh, libQtGTL-0.9.2.tar.bz2 (http://www.opengtl.org/) looks really interesting, but for me fails: libopengtl-dev is not available on 64bit ubuntu. Anybody has experience with that ?

@JubiluM/Alexander: Would make sense to write a easy-peasy opengtl-based QGraphicsEffectGTL class, and off you go ?!

muenalan says:

..and: The folks from Krita/opengtl had obviously some thought on c++ and shader effects:

http://cyrilleberger.wordpress.com/tag/shiva/

@Rupert says:

Granted, the binary contract is an issue.

However, a while ago, I asked around how I would do scenes with tens of thousands of objects in QML. The answer was basically “QML is not intended for that”.

What’s the point of performance if I can’t manage large scenes? I almost always have enough performance for small ones. I don’t really have anything to compare it to, but I don’t find Qt4′s performance to be all that bad.

M says:

I’ve got following problem:

m@m:~/qtlab/qtgraphicaleffects$ qmlscene tests/manual/testbed/testBed.qml
Qml debugging is enabled. Only use this in a safe environment!
No platform plugin argument was specified, defaulting to “xcb”.

Information of screen 349:
width………: 3840
height……..: 1080
depth………: 24
white pixel…: ffffff
black pixel…: 0

Running window manager: KWin
Cannot create platform GL context, none of GLX, EGL, DRI2 is enabled
QQuickCanvas: makeCurrent() failed…
QOpenGLFunctions created with non-current context
ASSERT: “context” in file opengl/qopenglfunctions.cpp, line 175
Break

JubiluM says:

@muenalan:
There already seems to be QtGTL library, libQtGTL (http://www.opengtl.org/download/). And of course writing code instead of whining is a relevant option :) . Problem is time and unfamiliarity with the inner guts of the codebase for many of us, since we’re mainly code end users, have a daytime jobs, families etc. But never know, since it’s all open source, at any time you might find an individual who has finished something you thought should have been done.

@Rupert:
“(Does QGraphicsView actually get people that wet, really?) I would like to see numbers on this (rather than my own claims) but the haters appear to fall in 2 camps:

1) Those missing desktop widgets (understandable and scheduled to be fixed with the launch of Qt 5)
2) Those who will never accept a scripting language on principle”

Actually, there are use cases where QGraphicsView is really important….if you do not need it, it’s ok. But you are making yourself an idiot by saying that nobody needs it. But you are right, would be really informative to see some numbers for example how many people/projects depend on widget qt and what would they think of the idea of rewriting their uis. I think a vast majority of Qt users are widget users at the moment. Some use both.

I think that even the ultimate widgeters do not have anything against qml, but of course feel threatened of the uncertain future of widgets (I know, it will be supported, maintained etc. etc.). But as you can’t deny he fact that the true development power is focused in qml, widgets do not get the love they used to. By arguing that one should go and use qml you just irritate people…they’re the experts of their programming tasks…nobody told them to use widget Qt in the first place, they found it themselves and fell in love.

Ok…1) is obvious and 2) needs some discussion. I’ll tell you that for some minority the 2) might be because of an attitude. However in many cases involving a scripting language into ones project is just an unbearable boundary condition. You might find it hard to believe but it’s just the way it is. There are many things involved…for example debugging, testing etc. where an additional language binding brings unwanted complexity. And I haven’t seen anybody addressing the problem related to not being able to use any other IDE than Qt Creatot….will one ever be able designing uis and building projects involving qml and use, say, Visual Studio? One strength of widget Qt is to let the user choose from almost any IDE or toolset there is.

There is a lot of passion on the subject but it just tells that many, many people care about the future of the Qt.

@Kaitsu:
“More QQuick* C++ can be provided as public APIs in Qt 5.x timeframe. ”

That’s good to hear. I am 100% sure that it’ll be highly appreciated :) .

Oliver Knoll says:

It is funny how some people want to put the C++/widget advocates into the “haters” and “never accept on principle” drawer, while at the same time trying to imply that performant applications can only be implemented using declarative/scripted user interaction.

First off, I appreciate the effort being put – both performance-wise and research-wise – into QML! I think it’s a great way to solve problems in certain domains, notably mobile devices and desktop games maybe. Heck, you might even do desktop applications with their “own look and feel” with it, why not!

And yes, designing your custom UIs might indeed be way simpler with a declarative approach such as QML.

Said all that, there are still a LOT of applications which simply want to conform to “desktop standards”, that is NOT having that “custom look and feel”. They need high performance graphics? They deploy a QGLWidget. They need fast image processing? They use an appropriate graphics library with highly optimised Gaussian blurs (maybe implemented using GLSL even). But for the rest they’ll just need plain old boring dialogs, menus, comboboxes and pushbuttons.

Do I need QML for that? Maybe. But not really: Qt already provides all that. And most importantly: in the language of my choice, C++.

So am I just stubborn and not wanting to learn JavaScript? Maybe. But mostly because I don’t consider JavaScript a good choice for writing LARGE applications (anything which goes beyond the typical 5 screen mobile phone “app”). Some reasons I fully agree with are given here, for example: http://arstechnica.com/business/news/2011/10/javascript-has-problems-can-googles-dart-solve-them.ars/1: No static typing (after having implemented stuff in both JavaScript and Python I still don’t get it why people cheer so much about dynamic typing – it’s one sad “Guess what that variable could be” game!), no module system, weird variable scoping, not to mention the need for yet another debugger.

And no, I really don’t want to ad yet another language into the C++ project when I can do without it! Spreading your UI logic across C++, XML and JavaScript files in LARGE projects is simply not the way to go.

So how do other frameworks do it?

Well, there’s Cocoa – all widget based! And we all know what great-looking effects you can get with that! To my knowledge there is no declarative approach, at least not from Apple (3rd party libraries might exist).

Then there is XAML from Microsoft, a declarative language for UI for their Windows Presentation Foundation (and Silverlight). The output? Widgets again! So you can design your UI in a declarative manner, but have “direct” access to it with the “native” language and can add/modify the created – ah yes – widgets.

And Qt? I wish QML was just a “nicer .UI” language which would produce “widgets” (not necessarily the QWidgets we know, but widgets with a C++ API!). There could still be a JavaScript binding to them, for people feeling about their apps in a more “webbish way”, people could still design UIs with their favourite XML editor (eeks!). But the rest of us could still interface those widgets with C++, and heck, even design applications in a “programmatic manner” (just as is the case now actually with UI files generated by Qt Designer).

THAT would have been my perfect Qt 5, not that separated QML/C++ world – yes, there are bridges, but they feel awkward and not build with much love (“you do have to get dirty with JavaScript and/or QML”).

So putting those of us which still love the widget world into the “haters drawer” is a bit childish, no?

My thoughts,
Oliver

Oliver Knoll says:

Oh, I forgot: The effects do look really cool – great work! :)

Cheers, Oliver

Wasabi says:

Oliver: Definitely not putting you into “haters drawer” with that clean post. But as QML has nothing to do with XML, can I put you into “partly misinformed, soon to see the light” drawer? ;)

Those of us writing desktop applications and being concerned/interested of how QML will fit there, please watch:
- http://developer.qt.nokia.com/videos/watch/qt-quick-components-for-desktop
- http://developer.qt.nokia.com/videos/watch/a-desktop-ui-with-qt-quick

Remember, it’s not ready yet. But when it is, it will be a very developer-friendly way to make UIs.

JubiluM says:

@Oliver Knoll:

Issues well described and adressed. +1

fonzi337 says:

This looks very interesting and looks like it would be an exciting addition for Qt 5. :)

I’m wondering how the performance of using these elements compares to using images in an embedded but hardware-accelerated environment. I’ve always heard that the use of the Gradient QML element is discouraged, due to how computationally-intensive it is. Do these new QML elements (particularly the gradient ones) suffer from the same performance issues? Are the gradients recalculated for every draw or is an internal image stored after the first computation and used after that until a recalculation is required (perhaps for a resize event)? Can this computation overhead be easily offloaded to the GPU? How does the performance compare with using the Image element and setting the source to an image that displays a gradient?

It seems that it would be ideal to use these new elements as opposed to the Image element, as these offer the flexibility of changing visual styles on the fly without the need to create a batch of different image files. Performance is just my concern.

Marko Niemelä says:

@Jobs: Perhaps you could achieve Tilt and Shift -effect by combining MaskedBlur (with a suitable alpha-gradient as maskSource) to achieve the depth-of-field part of the effect. Then maybe increase the color saturation a bit, for example by using the result from MaskedBlur as a source for HueSaturation-effect ?

@fonzi337: All these effects have a property called “cached”. If set to “true”, effect output is cached and it is drawn into the screen from an offscreen pixel buffer. That should be just as fast as drawing an image (assuming the effect properties are not animated which would cause cache update for every frame). Documentation has some more info about this.

Robert says:

@Oliver Knoll
+1

GreenScape says:

Really amazing! Thanks for your work.

Torsten Labs says:

Amazing!!

But i tried to create the API Documentation and i get allways this error:

‘qdoc3′ is not recognized as an internal or external command,

Does anybody know what this is?

Commenting closed.