Found IT!!. It is a QProgressBar that we are showing even though it has a value 
of 0. if I manually hide it until we start our progress then my applications 
Idle time goes to near 0%.

Seems like a pretty high CPU usage for just putting a QProgressBar into a UI.

Mike Jackson


On Jun 27, 2015, at 11:27 AM, Michael Jackson <[email protected]> wrote:

> I have tracked it down to our use of a QSplitter. If I hide our "left" side 
> then the CPU usage drops to 0~1% while idle. There is a QFrame Derived custom 
> class that is placed into the left side but that custom widget does not do 
> any custom painting that I am aware of. Still digging…
> 
> Thanks
> Mike Jackson
> 
> On Jun 27, 2015, at 10:58 AM, Michael Jackson <[email protected]> wrote:
> 
>> Our application seems to take more cpu than I think it should while just 
>> sitting "Idle". My machine is a MacBook Pro 2.6GHz Core i7 with 16GB Ram. 
>> Running OS X 10.8.5. Using the Activity Monitor our application takes about 
>> 10-12% of my CPU time. Using the "Instruments" application to get the 
>> heaviest functions I see that QImage::copy is taking up a bunch of time:
>> 
>> Running Time Self            Symbol Name
>> 2218.0ms   57.2%     2218.0          QImage::copy(QRect const&) const
>> 2218.0ms   57.2%     0.0              QImage::detach()
>> 2218.0ms   57.2%     0.0               QPainter::begin(QPaintDevice*)
>> 2218.0ms   57.2%     0.0                
>> QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, 
>> int, QPainter*, QWidgetBackingStore*)
>> 2218.0ms   57.2%     0.0                 QWidgetBackingStore::doSync()
>> 2218.0ms   57.2%     0.0                  QWidgetBackingStore::sync()
>> 2218.0ms   57.2%     0.0                   QWidgetPrivate::syncBackingStore()
>> 2218.0ms   57.2%     0.0                    QWidget::event(QEvent*)
>> 2218.0ms   57.2%     0.0                     QMainWindow::event(QEvent*)
>> 2218.0ms   57.2%     0.0                      
>> QApplicationPrivate::notify_helper(QObject*, QEvent*)
>> 2218.0ms   57.2%     0.0                       
>> QApplication::notify(QObject*, QEvent*)
>> 2218.0ms   57.2%     0.0                        
>> QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
>> 2218.0ms   57.2%     0.0                         
>> QCocoaEventDispatcherPrivate::processPostedEvents()
>> 2218.0ms   57.2%     0.0                          
>> QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*)
>> 2218.0ms   57.2%     0.0                           
>> QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>> 2218.0ms   57.2%     0.0                            
>> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
>> 2218.0ms   57.2%     0.0                             QCoreApplication::exec()
>> 2218.0ms   57.2%     0.0                              main
>> 0.0ms    0.0%        0.0                               Main Thread  0x2f66d0
>> 
>> I figured it was one of our custom paint methods. I went  through our 
>> project and systematically commented out all of our custom painting codes 
>> and there was no change. We do use a lot of CSS to style our widgets. Would 
>> that account for the high CPU usage? This is with Qt 5.4.1 downloaded from 
>> Qt.io.
>> 
>> QTimers maybe? We do some animations using QTimer, though that is supposed 
>> to be "on-demand", i.e. it is not a continuous animation.
>> 
>> I replicated the issue on OS X 10.10 with Qt 5.4.2 on that system. As a 
>> sanity check, QtCreator uses 0% while Idle. So I must be something that we 
>> are doing wrong in our app. Our application on Windows does not seem to have 
>> this issue either.
>> 
>> Thanks for any help or insights.
>> Mike Jackson
>> BlueQuartz Software
> 

_______________________________________________
Interest mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to