[Qt, OSX] QProgressBar CPU-Issue workaround #5296

fixes #5295

I know it's a bit of a hack. But it saves a lot of CPU ticks on OSX. You might decide to take this in because it does the job and the QTBUG-15631 seams to be open and untouched since 2010.

I'm not too happy about more and more platform-specific code, but if this is really required, fine with me.

Please do move the implementation to guiutil, though.

You can use a typedef to give the new name to the original class on non-Mac platforms, so the application code can be free of platform-specifics.

I also don't like it. But i like it more than useless burn cpu. It would bring back the possibility of a AppNapping and a Network-Disabling-Switch (some people might do the same like i do and block bitcoin-qt traffic with soft-firewalls to prevent cpu/network-bandwidth while on the go).

Is there a patch ready from Qt upstream that could be used during the build? I know we already include some patches during build time.

@Diapolo i did search for a qt patch but could nothing found. I also followed the idea of writing a qt patch (root cause fixing) but didn't succeed.

I just think we owe the user a more or less bug free bitcoin-qt client. This pull does not follow a state of the art architecture but makes the enduser experience better.

I try now to move it to guiutil and try to follow sipa's advice with the typedefapproach

@sipa i just implemented typedef "switch". But IMO it more unclear then. I would recommend to keep it as it was with the #ifdef directly while instantiating the object. I think it is better understandable and the code is shorter. What do you think?

I'll leave that up to @laanwj. I was just giving a suggestion on how you could keep the platform-dependence out of the application code.

Agree with @sipa; something like

#include <QProgressBar>
#ifdef Q_OS_MAC
#include <QEvent>

// workaround for Qt OSX Bug:
// https://bugreports.qt-project.org/browse/QTBUG-15631
// QProgressBar uses around 10% CPU even when app is in background
class ProgressBar : public QProgressBar
{
 bool event(QEvent *e) {
 return (e->type() != QEvent::StyleAnimationUpdate) ? QProgressBar::event(e) : false;
 }
};
#else
typedef QProgressBar ProgressBar;
#endif

Then in the code you can just do

progressBar = new GUIUtil::ProgressBar();

...would contain the platform specific code this to just guiutil.h. We just define our own progress bar class which happens to be different on a certain OS.

Okay. Now i see. I just updated the pull.

Making all in src CXX libbitcoin_util_a-clientversion.o AR libbitcoin_util.a CXX qt/qt_libbitcoinqt_a-bitcoingui.o In file included from qt/bitcoingui.cpp:10: ./qt/guiutil.h:199:42: error: no member named 'StyleAnimationUpdate' in 'QEvent' return (e->type() != QEvent::StyleAnimationUpdate) ? QProg... ~~~~~~~~^ 1 error generated. make[2]: *** [qt/qt_libbitcoinqt_a-bitcoingui.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1

Got this with current commit a574189e2acdaa03658bfe495740b2d722984467

What version of Qt? Probably it needs a version check too.

Admin@MacBookPro-3:~/Desktop/test/bitcoin $ brew upgrade qt Error: qt-4.8.6 already installed

OK - looks like this should be a Qt5-only workaround

Hmm.. Yes. The enum is only in qt5 available. I will wrap it in a Qt5 #ifdef.

Thank you guys!