tst_qgraphicsproxywidget: fix memory leak

Change-Id: Ib449dc05cebd333310d6ea6b434c9db7082bdee9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
QThreadPool: fix typos

Task-number: QTBUG-31919
Change-Id: I2718566595622895f182191b5693e91c1ab1e7d0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
configure: Abort if Xlib isn't present when building for XCB.

The XCB port is still incomplete and needs Xlib in several places.
The configure script should reflect that and make sure Xlib is present.

Change-Id: I6d81ea6cacef56084cf7ccfbcf908d597aae918f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Add benchmark for QThreadPool.

The current question is whether activeThreadCount() should be lock-free
(using atomic ints) or mutex-protected, so this tests start()
and activeThreadCount() directly.

Change-Id: Ica4a2ad023c2002e3c7d81558e6b9ee64af7f690
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
QUrl: fix host(FullyDecoded), it shouldn't trigger EncodeUnicode.

Change-Id: I9a62d5eb8b099b659cfcfc591c983b3d73ca9569
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QUrl: Use decoded mode by default for individual getters/setters.

This fixes the wrong value for path() and fileName() when a
path or file name actually contains a '%'.

userInfo() and authority() are not individual getters, they combine
two or more fields, so full decoding isn't possible (e.g. username
containing a ':').

[ChangeLog][Important Behavior Changes][QUrl and QUrlQuery]QUrl now
defaults to decoded mode in the getters and setters for userName,
password, host, topLevelDomain, path and fileName. This means a '%'
in one of those fields is now returned (or set) as '%' rather than "%25".
In the unlikely case where the former behavior was expected, pass PrettyDecoded
to the getter and TolerantMode to the setter.

Change-Id: Iaeecbde9c269882e79f08b29ff8c661157c41743
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QThreadPool: fix data races in activeThreadCount()

Rather than trying to make it lock-free (which requires double-bookkeeping of
4 atomic ints!), just lock the mutex before calling it.
tst_bench_qthreadpool shows no difference whatsoever between the two
solutions, I get 0.005 msecs per iteration in startRunnables().

Of course looping over calls to activeThreadCount() is a bit slower,
from 0.0002 msecs per iteration to 0.00027 msecs, i.e. 35% more.
But polling activeThreadCount() from the app is a really wrong thing to
do anyway, this benchmark was just for my own curiosity about the
price of a mutex in a function that sums up 4 ints.
What matters is start() performance, which is unchanged (0.00007 msecs
is just noise compared to a 0.005 total, that's 1.4%).

Change-Id: I993444eef8bc68eff9badd581fae3626dfd1cc6d
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>