Some days ago I was listening the radio and a famous Brazilian comedian was saying how stupid it is to express you thoughts about things because latter you probably regret what you said, and realize how dumb you are… although I partly agree with him I decided to share this as maybe someone is facing the same problems I’m facing.
I don’t want to spread FUD, so if my tests/conclusion or everything I said is wrong please explain and I’ll update or drop the text entirely 😛
Lately I’ve been working a lot on an Qt5/Quick2 application and I decided to share some thoughts about this new piece of tech. The application that I’m working on basically has to index >16k of videos and music files, and show their covers so the user can choose what to listen/see, it’s an app for jukebox machines. Xapian rocks!
First I need to say that I really like Quick2, the name is right about how fast can you write your app, on Quick2 we have some very cool graphics effects like blur, shadows and others, and those are quite interesting for this kind of app. I can blur the background, draw shadows on the CD covers and so on. The multimedia part is also very easy to use, so how to play a video or music file is not something you worry about (tho I need to find a way to play files that I encrypt stupid recorders).
Most people also probably heard about Scene Graph which is the new rendering of QML 2 which uses OpenGL (EGL iirc), this brings many improvements on performance and quality, and expands the QML2 possibilities.
However maybe you are considering it for your own projects, the QWidgets vs QtQuick is something many developers don’t know the answer yet. To me it’s now a bit more clear on what to choose.
Every now and then I listen people saying that OSX is good because it’s software made for the hardware, and while in parts I agree with that the same is valid for Quick2. Martin recently wrote an interesting blog about “what makes a lightweight desktop lightweight“, which describes the problem of properly describing a technology.
My point is that with Quick2 we need to set a barrier between legacy and supported hardware, to me this is quite complicated because you can have some very powerful CPUs from like 8yo coupled with very slow GPU, and brand new hardware with the opposite configuration, Raspberry PI for example has a rather slow CPU with a great GPU.
So while QWidgets/Quick1 performed quite well on those old machines Quick2 doesn’t. To exemplify I have a computer to test my jukebox application that has a crap VIA graphics with a 3.2 intel D CPU. When I went to deploy/test my super cool and animated application there, I almost cried, after removing blur/shadow/transparency effects I could get a maximun of 10fps on fullscreen with 1024×768. Toggling the composite switch didn’t make any difference (nice work KWin team), and using other Window Managers also didin’t improve the poor experience.
Aaron give me a hint about llvmpipe, which is something I had heard but never truly understand what it was, basically llvmpipe is a software render for this exactly case where the GPU can’t handle the OpenGL instructions, but after some investigation it seems all new distros have it to render on these poor GPUs. Now that I knew about it I went to look at CPU usage and it was pretty high and leaking…
Before you jump on the wrong conclusion that Quick2 is bad please note that for any hardware capable of OpenGL it’s an excellent choice because it can offload the rendering stuff from your CPU to the GPU. And this is where we have a new era of “lightweight” of desktops as they use less CPU.
Something that does bother me is that Plasma 2 will need newer hardware specs, I won’t be able to run KDE SC 5 (or whatever it will be called) on such hardware, I went on thinking that it would be nice to have something like lxde-qt as our QWidget shell and still use Qt5 with our KDE stuff. On the long run I believe we won’t be able to share much of the GUI apps as Quick2 will probably become more and more common, not to mention it’s a nicer way of developing GUI stuff.
And if you wonder what I’m going to do, I not totally sure, but right now I have 2 user interfaces on the same binary, one QWidget based and another Quick2. I thought about going back to Quick1/Qt4, but then I wouldn’t have the cool Quick2 stuff. Thanks to the model based approach I’m sharing most code between the two interfaces. And yes, since QWidget on Qt5 still uses raster rendering it provides a much more responsive experience for the application.
I hope this gives you some clarity if you might be targeting hardware like that, in the future I hope to be able to deploy on Raspberry PIs but the lack of RTC doesn’t make it an option right now.
If you know some magic way to improve FPS please let me know, I’d love to have a single GUI 😀
Dantti's Blog 
Only if you actually do crazy things that need the graphics card (i.e. computing-intensive tasks such as blurring), you’ll have to have a fast graphics card.
There is no reason, however, to say that Plasma 2 will need newer hardware. We can still choose to use things like blur effects or not. So given a shell with the same amount of “eye-candy” (heavy effects really), there’s no reason to say that Plasma 2 will be slower on certain hardware. The worst case scenario is that your rendering stack falls back to llvmpipe, in which case it will be computed on the CPU. If available, the GPU can be used for that (using a native driver).
Thus, a correct representation would be: It will be at least as fast, but likely faster.
Consequently, a solution for the performance problem in your application would be: reduce computing-intensive graphical effects, for example disable your blur and shadow code for slower hardware. You don’t need QWidgets to do that.
As I said I removed all the effects and still got 10fps, the app had only 5 Text elements and 9 CD covers, with a blank background. Surely just the Kickoff will have more elements than my app…
So no, it won’t be “as fast”, because it will fallback to llvmpipe and it is slower than raster depending on the processor, there was even a Qt bug to have raster back to Quick2 but it won’t happen.
There’s always a trade-off between utilizing new hardware features and supporting old hardware. The question is just when is the right time to switch. You could easily argue that now is not the right time, that it is too early. However, KDE 5 won’t be widely used until late next year I suppose, and I think at that point it’s ok to require OpenGL.
Of course it would be ideal to have an acceptably fast fallback with software rendering. I don’t have first-hand experience with llvmpipe, but I’m very interested in the technology. Hopefully others can shed some light.
Sure, I’m not against it’s using in KDE SC 5, I have hardware capable of that, actually my app on a 2007 MacBook and intel chip manage to render at 60fps after enabling caching of all effects, you can have good OpenGL on old hardware, and no OpenGL on not so old ones too.
This is a real problem which will need some solution. There are some use cases (servers, virtualization) where even llvmpipe could not be the right solution. For sure the separation between model and view helps a lot (more interfaces using the same data and logic, as we have now, see Okular/Okular Active and many others).
But btw, have you seen this? Maybe it could be the solution…
https://conf.kde.org/en/Akademy2013/public/events/20
Well if you want a DE on a server imo lxde/razor would be the best options, since they have less visual effects and thus are cheaper to send via VNC.
Also I don’t think this is a problem, it’s more like a new requirement than an issue (it is an issue if you are willing to deploy it on not capable hardware), this also doesn’t make our software more “heavy” (it will use less CPU), nor it necessarily uses more RAM (my app with a loaded model and all QML inside the binary uses 20mb).
About the link Qt 5.1 does include that but that isn’t an alternative to hardware not capable of OpenGL it is just the possibility to use “native” widgets in QML/Quick 2, which will suffer from the same need.
The link is about Declarative Widgets, not QtQuick controls.
You can trust me on this I gave that talk 🙂
Oh my mistake 🙂 I’ll look at the slides later… but still it’s not relevant for the rendering part, right?
“this also doesn’t make our software more “heavy” (it will use less CPU), nor it necessarily uses more RAM (my app with a loaded model and all QML inside the binary uses 20mb). ”
This is really splitting hairs, right? You are arguing that something that requires newer hardware to run is not “heavy”?
>You are arguing that something that requires newer hardware to run is not “heavy”?
Yes, the RapberryPi has a processor (according to their website) comparable with a PentiumII, and the GPU comparable with XBox first gen, and still it has enough power to run my app with several effects, where the old hardware with much, much more processing power 3,2Ghz can’t because of it’s GPU.
An application that frees the CPU to do other tasks such as decoding a MP3 and renders itself on the GPU can’t be called heavy.
Not sure what you mean with “relevant for the rendering part”.
QWdgets are rendered through the raster paint engine in Qt5 and I think also by default in Qt4 but with the option of rendering using low-level X11 drawing API on X11 systems.
Obviously independent on whether the widget objects in questions have been created by C++ code, loaded from UI file or created by a QML document
“QWidgets vs QML is something many of developers don’t know the answer yet”
It is a non-sensical comparison, nothing prevents you from using QML with QWidgets.
Maybe you wanted to write “QWidgets vs QtQuick”?
Yes, I’ll update the text, thanks.
AFAIK you can still use QtQuick1 with Qt5, if that works for you. At least you don’t need to have two sets of UI implementation.
Yes, but then I’d miss all the good stuff like blur and shadows… and I’m not sure if QtQuick1 would be rendered on raster, but maybe if I could have only little difference in the sources it would be indeed better. I think I’ll try to see if it could work so it would mean less different stuff.
It’ll render on raster (or to put it more correctly, with the old QPainter API that supports raster).
Anyhow, QtQuick1 is meant really more like a porting tool, and there are actually discussions to deprecate it already for 5.2. So I wouldn’t recommend anyone to start new projects with it unless it’s crucial for you to keep things working with Qt Quick 1.
In the end I think one has to bite the bullet: For apps with a more conservative UI llvmpipe should be fine. For apps with animations, effects etc you have to require a non-crappy graphics card.
Right, so I’ll just keep my QWidget UI.
And I have to disagree with you at the end, llvmpipe has a reasonable performance on some machines, on my MacBook for example it renders just a little slower than without it. But on that testing machine being conservative or not doesn’t make a difference, a really simple ListView with some images is very unresponsive at 10 FPS… Also for the record GLXgears also renders at this speed when on fullscreen.
and I believe Gnome3/Unity wouldn’t run well on that machine as iirc they are also requiring EGL.
Can’t you put raspberry pi in the jukebox?
Yes, and no. 😛
I plan to do that in future (which is why I’ll keep the two GUI around), but right now I have two issues with it:
* It doesn’t have Real Time Clock, a must since there is no network to get the right time
* It lacks SATA and PS2 tho both I could work around.
Basically the idea is to use it (or some other in the future) but right now I need something that works with cheap x86 hardware…
How bout Beaglebone as mediabox 🙂 http://www.digikey.com/product-highlights/us/en/texas-instruments-beagleboard/685?WT.srch=1&WT.medium=cpc&WT.mc_id=IQ59985735#beagleboneblack
it seems to also lack RTC 😛
That’s not really a big problem and easily solvable on both boards. There are lots of simple I2C RTC circuits ICs avalible, making a RTC add on module is rather uncomplicated. You may even find premade Beagle shields available or something in the Aurdino world.
Yes, I know it’s possible to build those but right now I don’t have the time, still need to finish the UI, cypto part and need to pay some money so that it is legal for the recorders.
Doing a quick Google, it really does seem quite easy to add an RTC to a beagleboard.
http://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/overview
It means setting aside half a day to get it working (though it might take half an hour) but it sounds like it would be well worth the time in order not to have to keep worrying and second-guessing your design decisions Re QWidgets and QtQuick.
Hmm thanks, I have a PI and I saw one of these but I don’t have much experience with building these board, but my wife does and she said it’s probably easy to do 😛
I guess I’ll just forget about this QWidget one…
Now I need to get Qt5 on my PI 🙂
> it seems all new distros have it to render on these poor GPUs
no, of course not. Just use env variable LIBGL_ALWAYS_SOFTWARE=1 and you are ready to go. For full overview of available env variables check http://www.mesa3d.org/envvars.html
Martin, when I run glxgear -info with or without that var it always shows llvmpipe as the render, having this var on my Qt5 app also didn’t change the rendering performance. So my conclusion is that it was the default fallback, I might be wrong but from my tests that is what happened.
In that case your blog post is misleading as it sounds like the GPU is used while in trught the cpu is used. llvmpipe is the software rasterizer – the env variable works correctly. I use it from time to time to test KWin on llvmpipe 😉
[…] Thoughts on Quick2 […]
llvmpipe is not the solution and people should stop pretending that it is. It’s just a convenient argument for those who don’t want the (admittedly massive) incovenience of another backend for QQ2.
On really fast CPUs, llvmpipe *may* sometimes reach usable frame rates.
On older hardware without OpenGL support, llvmpipe pretty much guaranteed to be too slow.
While it’s probably not worth fixing, please admit already that users who want QQ2 but have no OpenGL are screwed.
Agreed, since on the news it’s said that Gnome/Unity will rely on llvmpipe for when missing OpenGL, imho I think these user don’t need llvmpipe they need something that doesn’t require OpenGL, so I just hope there will be projects like razor/lxde-qt to fill that gap.
Hi dantti,
Thanks for your “answer” about QWidgets VS Quick1 VS Quick2 🙂
My colleague @sonald benchmarked the example qtdeclarative/examples/quick/demos/maroon on iOS7 (iPhone 4S), he hold the view that the rendering part is TOOOOO heavy…
So may I argue that QML2 && Quick2 is not suitable for the embedded enviroment? but it is OK for the desktop, isn’t it? perhaps Qt developers need to optimize the QML2 && Quick2 🙂
And I also want to see the QML2 && Quick2 performance, so developed a PackageKit frontend for iSoft Client OS (a Linux desktop distribution based on ArchLinux) based on Qt5.2.x && QML2 && Quick2.
We chatted @github https://github.com/nemomobile-packages/PackageKit-Qt/issues/4#issuecomment-38202828 did you remember 🙂
The frontend (for desktop) performance is good, and the interesting part is SLOC cpp is 1040, qml is 1401! QML ROCK 🙂
Regards,
Leslie Zhai
Well some of the examples aren’t mobile optimized, I have friends doing mobile stuff with Qt and it runs as fast or even fater than native apps.