vstevenpa...@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
-project.org; VStevenP vstevenpa...@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
idle widgets of various types?
- VStevenP
From: Jason H scorp...@yahoo.com
To: VStevenP vstevenpa...@yahoo.com; interest interest@qt-project.org
Sent: Friday, January 10, 2014 4:47 PM
Subject: Re: [Interest] QtQuick/QML performance issue
Very correct sir.
I
...@yahoo.com; interest interest@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
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%
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
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
