[Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

[René J.V. Bertin]

On Monday August 28 2017 23:10:22 René J.V. Bertin wrote:

I found a potential fix: shouldn't QCocoaMenu::timerEvent() call

        killTimer(m_updateTimer);

before setting m_updateTimer=0? Whether or not it's appropriate, this does solve the CPU burning for me.

R.

> Hi,
> 
> I noticed an annoying change after doing the periodic merge of changes in the qtbase/5.9 branch with my standalone Cocoa QPA.
> Commit f27d1ccbb24ec2fd4098f2976503478831006cc8 introduced a delayed invocation of [NSMenu update], which looks like a good idea. However, in some applications, including the Assistant, this somehow causes QCocoaTimer::timerEvent() to be called continuously, always with timerId 454.
> 
> That's in Qt 5.9.1 (stock, release) but also in my own patched Qt 5.8.0; the former with the standalone QPA backported to OS X 10.9 and for the latter, backported to Qt 5.8 too.
> 
> I cannot really imagine that this is an effect of the backporting; QTimer has been around for too long and the consistency of the id=454 timer suggests something else is going on.
> 
> The other applications in which I notice the CPU burning issue are KDevelop and Creator : like Assistant they both use QtHelp functionality.
> 
> Thanks,
> René