[Interest] QtQuick/QML performance issue

Sat Jan 11 02:31:58 CET 2014

I think it's a eglfs issue. eglfs uses opengl fullscreen. opengl does not
support partial screen updates - everything has to be redrawn when anything
on screen changes. If opengl drawing is the one that takes all the CPU,
then we can explain it. Even if nothing has changes in the other widgets,
depending on how complex ypur widget, it may take a bit of CPU to render
it.

What I don't understand is, the new scenegraph in 5.2 is designed to
improve performance in exactly these kind of situations by batching
drawing, uploading and retaining geometry etc.

One test would be to check CPU scaling with raster backend - what CPU usage
you see with one widget and 20.

On Sat, Jan 11, 2014 at 5:59 AM, VStevenP <vstevenpavao at yahoo.com> wrote:

> Hi Jason,
>
> I do understand about the single core vs multicore issue, and it's good to
> make sure that's not the issue.
>
> I believe I'm got the same metric here with BeagleBoard-xM, Ubuntu in a
> Parallels VM, on my Mac and Mac native: CPU% per core.  If I was measuring
> CPU activity on Windows 7, that would be different, because I believe the
> CPU% on Win7 is expressed as a % of the total # of cores.   On Mac however,
> 100% CPU means one core, and if a CPU% number exceeds 100% that means > 1
> core.
>
> So, the search goes on to try to understand the difference between the
> Ubuntu and BB-xM (per-core) CPU% numbers.
>
> It would really help if one of the Qt ARM experts could chime in, maybe
> Thomas Senyk who gave a presentation about Qt on ARM at Dev Days 2012 could
> advise.
>
> Why do the observed CPU% usage numbers skyrocket for BB-xM when editing a
> widget where the app contains a bunch of other idle widgets of various
> types?
>
> - VStevenP
>
>   ------------------------------
>  *From:* Jason H <scorp1us at yahoo.com>
> *To:* VStevenP <vstevenpavao at yahoo.com>; interest <interest at qt-project.org>
>
> *Sent:* Friday, January 10, 2014 4:47 PM
>
> *Subject:* Re: [Interest] QtQuick/QML performance issue
>
> Very correct sir.
> I just wanted to make sure you were't using a raster backend due to some
> configuration problem. When I was working with QML and video, the backend
> varied top widely depending on what backends were invoked. It took some
> tweaing to get it down to a reasonable level.
>
> Also, its not Angrstom vs Ubuntu, it is BB-xM vs a multicore desktpop.
> Realize how top handles multicore systems. 100% is possible per core, on a
> HT Quad, you can get 800% usage. In a multprocess, multi-threaded app, you
> have more cores to move the processing around on. So perhaps the  numbers
> for the app don't include all the various tasks, which on BB-xM could only
> ever be on one core.
>
>
>   ------------------------------
>  *From:* VStevenP <vstevenpavao at yahoo.com>
> *To:* Jason H <scorp1us at yahoo.com>; interest <interest at qt-project.org>
> *Sent:* Friday, January 10, 2014 2:25 PM
> *Subject:* Re: [Interest] QtQuick/QML performance issue
>
> 'top' on Ubuntu reports a reasonable number of 5% CPU when editing my
> simple Knob widget when there are lots of other idle widgets in the app.
>  On BeagleBoard-xM, 'top' shows 45%.  That's quite a variation for 'top' on
> the 2 Linux-based systems.
>
> I am using EGLFS.  When I run QML Profiler locally on my app on either
> Ubuntu or Mac, it shows that the app runs nice and lean on each of those
> platforms.
>
> It is my understanding that invoking qmlscene directly is good for
> prototyping, but not recommended for a delivered product.  I am not
> invoking qmlscene directly because I am beyond prototyping, and because
> qmlscene is not for production, and also because I have custom C++ classes
> which I expose to QML language via qmlRegisterType().  So, I need a .pro
> file which results in building an executable.
>
> I will try to run a QML Profiler (External) session against my app when it
> is running on the BB-xM.  I'll run QtCreator on Mac or Ubuntu for this. To
> achieve this, I think I must do another cross-build of qt 5.2 where I must
> reconfigure for -debug, and I wonder if I also have to add QML_DEBUG to the
> CONFIG in the .pro file.  QML Debugging checkbox is enabled in my project,
> so I think I may not need to manually add QML_DEBUG.
>
> Any way, it seems strange that 'top' on BB-xM/Angstrom would report wildly
> different results than 'top' on Ubuntu.
>
> - VStevenP
>
>   ------------------------------
>  *From:* Jason H <scorp1us at yahoo.com>
> *To:* interest <interest at qt-project.org>; VStevenP <vstevenpavao at yahoo.com>
>
> *Sent:* Friday, January 10, 2014 12:28 AM
> *Subject:* Re: [Interest] QtQuick/QML performance issue
>
> I would not trust top. How it is counting the time slices and how you are
> using them may not match reality. I would try to overload it, rather than
> say 20 is half of your processing power.
> Some things take different amounts of CPU, but take time slices. On that
> board you should be hardware GL and using qmlscene, either way drawing is
> minimal. The only qurstion is how much Java script you are running?
> Sent from Yahoo Mail on Android<https://overview.mail.yahoo.com/mobile/?.src=Android>
>
>  ------------------------------
> * From: * VStevenP <vstevenpavao at yahoo.com>;
> * To: * interest <interest at qt-project.org>;
> * Subject: * [Interest] QtQuick/QML performance issue
> * Sent: * Thu, Jan 9, 2014 8:02:06 PM
>
> I'm trying to understand a curious performance problem I observe in my
> QtQuick apps.
>
> First off, here's something good:  If I have a simple app that contains
> one Knob widget, editing that knob causes 'top' to show a CPU% of ~7%
> (typical) and ~15% (max).  When the app is idle, top reports CPU% of 0.
>  This is all good.
>
> However, if I add 20 different widgets to the app, then do the same edit
> test on that single Knob, 'top' shows a CPU range that is now in the
> ~30-40% range and ~45% (max).    When the app is idle, top again reports
> CPU% of 0.
>
> Why does the single edited Knob appear to use so much more processing
> power when there are a number of other idle widgets in the QtQuick app?
>
> I am observing this on a BeagleBoard-xM, which is a supported platform for
> Boot to Qt.  I have cross-built Qt 5.2 for ARM with configure -release.
>  The BeagleBoard-xM is running at top speed on the GPU and CPU (400/1000).
>  DVFS features are not engaged.
>
> I really needs to find out if I can make a Qt Quick app which runs on the
> BB-xM that can have a couple dozen widgets and when I use one of them, it
> will not use so much of the CPU.
>
>
> Does anybody have any ideas how to avoid this problem?
>
> - VStevenP
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
>
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140111/b4e90ac7/attachment.html>