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é
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
