When interfacing with reality (i.e. native platform APIs provided in C,
ObjC, or COM), each of the APIs has its own idea of what types it likes
to use for sizes, points, rects, etc.
Out of the hundreds of warnings Qt Creator throws at us with the default
clang check level when opening one of the rhi backends not a single one
is useful. Regardless, let's try getting rid of what we can. This mostly
involves throwing in int/uint conversions in order to get the signedness
change warnings to shut up. The things that are either unacceptable to
change or are beyond our control are left untouched.
Change-Id: I6e4cb7cd373bf48dc990eaf83344242bbf30bd66
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
QColorVector and QColorMatrix are default-constructed following the
Qt philosophy of types always being well-defined. The corner-case where
we need uninitialized versions of these types for performance reasons
is handled explicitly.
Change-Id: I629334d1ffc63563ec9fd1298c623946e0799d1d
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The device can be lost when physically removing the graphics adapter,
disabling the driver (Device Manager), upgrading/uninstalling the
graphics driver, and when it is reset due to an error.
Some of these can (and should) be tested manually, but the last
one has a convenient, programmatic way of triggering: by triggering
the timeout detection and recovery (TDR) of WDDM. A compute shader
with an infinite loop should trigger this after 2 seconds by default.
All tests in tests/manual/rhi can now be started with a --curse <count>
argument where <count> specifies the number of frames to render before
breaking the device. Qt Quick will get an environment variable with
similar semantics in a separate patch.
Change-Id: I4b6f8d977a15b5b89d686b3973965df6435810ae
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Found while cleaning up SPDY remains: I've noticed that for H2 case
I never check if incomingSslConfiguration is nullptr or not, but
the code several lines below - does it, which looks kind of moronic.
This configuration is initialized when the delegate is created, so
no need to have this if-statement. Instead, assert, making this
behavior a requirement.
Change-Id: I90fb84337be925a3288252aa2491b4c23d6c6cbb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
At first glance, libraryPathMutex is only recursive because
setLibraryPaths(), addLibraryPath() and removeLibraryPath(), all of
which lock libraryPathMutex, may call libraryPaths(), which does, too.
This is easily fixed by splitting libraryPaths() into public
libraryPaths() and private libraryPathsLocked(), the latter expecting
to be called with the libraryPathMutex already held. And this is what
this patch does.
However, on second glance, the building of the initial app_libpaths
calls a monstrous amount of code, incl. QLibraryInfo, and some of
that code probably re-enters one of the library-path functions.
So while this patch is a step towards making libraryPathMutex
non-recursive, it's probably not the end.
Change-Id: I3ed83272ace6966980cf8e1db877f24c89789da3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Results on my machine:
PASS : tst_QReadWriteLock::writeOnly(QMutex)
RESULT : tst_QReadWriteLock::writeOnly():QMutex:
3,607 msecs per iteration (total: 3,607, iterations: 1)
PASS : tst_QReadWriteLock::writeOnly(QReadWriteLock)
RESULT : tst_QReadWriteLock::writeOnly():QReadWriteLock:
39,703 msecs per iteration (total: 39,703, iterations: 1)
PASS : tst_QReadWriteLock::writeOnly(std::mutex)
RESULT : tst_QReadWriteLock::writeOnly():std::mutex:
3,697 msecs per iteration (total: 3,697, iterations: 1)
PASS : tst_QReadWriteLock::writeOnly(std::shared_mutex)
RESULT : tst_QReadWriteLock::writeOnly():std::shared_mutex:
5,727 msecs per iteration (total: 5,727, iterations: 1)
PASS : tst_QReadWriteLock::writeOnly(std::shared_timed_mutex)
RESULT : tst_QReadWriteLock::writeOnly():std::shared_timed_mutex:
5,921 msecs per iteration (total: 5,921, iterations: 1)
(the 'nothing' test of course doesn't work with writing, as writing to
the same QString from different threads is UB)
Change-Id: Ia78b54963a51eaf6563ce0d243316a3337056a83
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In QImageReader, also replace a QMutex with a QBasicMutex, making the
code similar to the corresponding code in QPicture.
Change-Id: Ia1cd546eccd3662837762e506235e350b7a08647
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By setting the accepted action to be the one from the response it will
enable the user to set the drop action in their code and this will be
reflected at the platform level.
Change-Id: I7b9459b228c00ef01d91649b3405316729713164
Fixes: QTBUG-77427
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Cleanup QtWidgets tools examples:
- use member-init (clang-tidy)
- fix includes/don't include QtWidgets globally
- include own header first
- use nullptr (clang-tidy)
- avoid c-style casts
- use QVector instead QList
- use QItemDelegate instead QStyledItemDelegate
Change-Id: Ibe9440cdf711e5cc2138c054864edebe1fc95731
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
We need to have the right idea of robustness, so check for extension.
Fixes: QTBUG-78107
Change-Id: I26987269e5c50bee20e2e3cc6d75f91a6c9af25e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
QFileSystemWatcher has open bugs, so users should be able to help
troubleshoot.
Change-Id: I6b703e25f294944469d20fd36012b6a55133732a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Found while preparing SPDY retirement.
Change-Id: I30f923fdeb0f6f0b5e808a3e7b7d81ddb9c4ef12
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If an app wants use a debug framework of Qt, it is still expected that
the app should link against the release version, and just set
DYLD_IMAGE_SUFFIX=_debug when running the app.
This was not the case before, where the CMake Config files told CMake
to link explicitly against the debug libraries. This caused crashes
due to the Qt plugin loader mechanism still trying to find a release
platform plugin, which in turn would load release libraries, and thus
the application would end up loading both debug and release plugins.
Make sure the Config files in a framework case always reference the
release libraries (even though this might be counter intuitive).
Otherwise users of the Debug Config files would always get
crashes.
Fixes: QTBUG-78131
Change-Id: I88b1dc421477ad186012ca67b328a891128eb568
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
src/corelib/global/qnamespace.qdoc:3279: (qdoc) warning: Can't link to 'QGuiApplication::setHighDdpiScaleFactorRoundingPolicy()'
src/corelib/time/qislamiccivilcalendar.cpp:49: (qdoc) warning: Can't link to 'QJijriCalendar'
src/network/ssl/qsslsocket.cpp:1510: (qdoc) warning: Can't link to 'QSslConfiguration::defaultCaCertificates()'
src/network/access/qhttp2configuration.cpp:49: (qdoc) warning: '\brief' statement does not end with a full stop.
src/gui/text/qtextformat.cpp:532: (qdoc) warning: Undocumented enum item 'TableBorderCollapse' in QTextFormat::Property
src/gui/text/qtextdocument.cpp:2066: (qdoc) warning: Undocumented enum item 'UnknownResource' in QTextDocument::ResourceType
src/gui/kernel/qguiapplication.cpp:3500: (qdoc) warning: Undocumented parameter 'policy' in QGuiApplication::setHighDpiScaleFactorRoundingPolicy()
Change-Id: I3573ef98cf9b58d16525c356270fe009fdffcf45
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Cleanup QTableWidget autotest:
- use range-based for loops where possible
- use nullptr
- use member initialization
- use new signal/slot syntax
- remove a lot of C-style casts
- use static invocations
- use override
- instantiate objects on stack instead of heap to avoid memleaks
Change-Id: I99ed144caab88d648d5ab987ce0963fbc6f1197d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
QSharedPointer is made for passing around by value. It is unclear why
in so many repeated cases a QSharedPointer is created on the stack,
then a copy of it is new'ed up, passed into a lambda to be deleted
inside it.
First, it requires an additional heap allocation. Because it's passed
as a raw pointer to QSharedPointer, however, there's also always the
danger that it's leaked by seemingly-innocuous changes such as adding
an early return from the lambda (and some of them could really use
one, with the ifs nesting several levels deep).
All this is not needed, though. It's perfectly ok to store a copy of a
QSharedPointer, by value, in a lambda, and keep one copy outside
it. Poor man's std::future, if you will.
So, do away with all that, just pass the shared pointer by value into
the lambda, and, as a drive-by, replace some ephemeral QLists with
QVLAs. In one case, replace a QPair<int, int> with a struct to make
the code using that type more accessible ('first' and 'second' are
really, really bad variable names if they, in fact, represent
'startOffset' and 'endOffset').
Also port directly to shared_ptr / make_shared. Saves one memory
allocation each, due to the co-allocation of payload and control
block, and even though there's QSharedPointer::create, which does
this, too, std::shared_ptr is simply much lighter on the use of
atomics (copying a QSP ups two ref counts, copying a std::shared_ptr
just one). Since these variables live behind the API boundary, there's
no reason not to prefer the more efficient alternative.
Change-Id: I4b9fe30e56df5106fc2ab7a0b55b2b8316cca5fe
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The volume names displayed did not match those of Windows
Explorer; for example "New Volume (X:)" would be displayed for
mapped network drives.
Replace GetVolumeInformation() and manual formatting by the
normal display name of IShellItem.
Fixes: QTBUG-78043
Change-Id: Ia742b7733e8ddc31e9506f15d90d065b985a111d
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
The constructor taking a QWidget is needed for specifying the screen
where the splash screen should be displayed.
Add a new constructor for specifying the target screen for the splash screen
directly, instead of "extracting" the screen information from a widget.
This removes the need for using the deprecated QDesktopWidget.
Deprecate the constructor taking a QWidget.
Task-number: QTBUG-76491
Change-Id: I1dde242ff5f7b53e52af308bb685f492d6266d33
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
GDI and the software rendering opengl32sw.dll may have very different
pixel formats so use wglDescribePixelFormat() in that case. This mirrors
the existing behavior for SetPixelFormat().
Change-Id: I55e658ab69bad84bb10cc5a042d62e84c005c0e6
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Since b3fc5e1ea3,
topData()->initialScreenIndex has always been short-lived: it only
remembers the screen in case the widget parent is a QDesktopScreenWidget
(gotten from QDesktopWidget::screen()), only until the window is
created. Then it is reset. In the case of exec() we need to avoid
calling setScreen() twice, because that would set the screen once, then
forget which screen it was supposed to be on, then set the screen again
when exec() calls popup(). This is achieved by using the stored
eventLoop pointer to detect that popup() is being called from exec(),
and avoid calling setScreen() a second time in popup(), because exec()
already needed to call createWinId() before it created the event loop.
Amends 82da8306bc
Task-number: QTBUG-76162
Change-Id: I70da517b9d530630e59d103cb2a1ce11c897b2c8
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Joni Poikelin <joni.poikelin@qt.io>
It's not a failure state, we just need more data. It is handled properly
in other functions.
Change-Id: I9450a78c71a3f4fe9506a7a79de6efa2db08697c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The reason it wasn't working before was a couple of things:
1. Due to an extra 'else' it would not process the SEC_I_RENEGOTIATE
or SEC_I_CONTEXT_EXPIRED branch.
2. The peerCertVerified boolean was not only wrong, but also
broke renegotiation even if the 'else' wasn't there.
My previous attempt to fix it ended up being a noop, so:
Reverts e21fa577dd
Change-Id: Ifbad55d4bb066b7566bb88cead48e329cbd574f9
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
commit 900f2cb6f7 removed this from the condition, which breaks the
(common) case of having QT_AUTO_SCREEN_SCALE_FACTOR=0 and
QT_SCREEN_SCALE_FACTORS set. This used to obey the screen scale factors,
so it should still do so (despite the deprecation warning).
This is what the Plasma `kcmshell5 kscreen` module actually sets (via
startkde).
Change-Id: I5f4efed11b937498049ebf1b107954721cf54147
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The documentation for textHighlighted/textActivated was not added within
bdf1c4f671 so add it now.
Change-Id: Ifa7ad72af4490d4ce1d6de00d0963c0e76013f42
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Now that Qt Quick's batch renderer misses one level of shader source
caching due to the nature of pipeline state objects, it can be useful
to keep and reuse shader objects when the hash of the source code
matches.
The goal here is to allow Qt Quick to be on par with what the direct
OpenGL path has when it comes to caching shader sources and compilation
results. The program binary disk cache is not in scope in this patch.
Also adds QRhi::releaseCachedResources(), similarly to what the scenegraph
has. This can be called to clear caches such as the shader object
cache we keep here.
Change-Id: Ie3d81d823f61fa65ec814439e882c498f7774d43
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
The test is not failing anymore on QEMU targets.
This partially reverts commit
71bd06d516.
Fixes: QTBUG-71915
Change-Id: I68593edf0ec245e14879833c8aa90661a3c2e227
Reviewed-by: Liang Qi <liang.qi@qt.io>
QWindowsOpenGLTester used Direct3D9 to determine GPU properties such
as the vendor ID. Prefer the more modern DXGI, if available.
Change-Id: Ie6b20dbe2d69bacb28d5d4e4e3459709ddc58537
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
BT.2020 is an HDR color space and its luminance range doesn't match
that of the rest of the currently available color spaces. Without
support for white-point luminance in 5.14, there would be a behavior
change when luminance support is later introduced, so it is better to
remove it now, and reintroduce it when the necessary handling of
different luminance levels is available.
Change-Id: Ie29e4dd757faae3ac91d4252e1206acce42801dc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QList<QRect> is horribly inefficient™. Since the container only lives
for the duration of the function call, use QVLA instead.
Change-Id: I2d179caef37bb78efface5547ff8bfcdc8f9a6ac
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
[ChangeLog][QtCore] Qt installations on the host system can now be
relocated, i.e. moved to other directories.
Add a new feature 'relocatable' that's by default enabled for
non-static builds
- on platforms where libdl is available,
- on macOS when configured with -framework,
- on Windows.
If the feature is enabled, the directory where plugins, translations
and other assets are loaded from is determined by the location of
libQt5Core.so and the lib dir (bin dir on Windows) relative to the
prefix.
For static builds, the feature 'relocatable' is off by default. It can
be turned on manually by passing -feature-relocatable to configure. In
that case, QLibraryInfo::location(QLibraryInfo::TranslationsPaths) and
friends will return paths rooted in the user application's directory.
The installed and relocated qmake determines properties like
QT_INSTALL_PREFIX and QT_HOST_PREFIX from the location of the qmake
executable and the host bin dir relative to the host prefix. This is
now always done, independent of the 'relocatable' feature.
Note that qmake is currently only relocatable within an environment
that has the same layout as the original build machine due to absolute
paths to the original prefix in .prl, .pc and .la files.
This will be addressed in a separate patch.
Task-number: QTBUG-15234
Change-Id: I7319e2856d8fe17f277082d71216442f52580633
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When Qt was configured with -libdir different from "lib", one could not
build with CMake whenever a static lib was pulled in (e.g. uitools).
Do not hard-code "/lib" but use the correct variable also for static
libraries.
Fixes: QTBUG-76255
Change-Id: I28c6861752e29e461247628d2b1f8a9ec32f0790
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de>
Instead of assuming they do not (like in >= 5.12.3) or they do (like
in < 5.12.3). QOpenGLWidget and QQuickWidget will likely want the
opposite. So allow specifying this with a QPlatformTextureList flag,
similarly to how we do it for sRGB for QOpenGLWidget.
Task-number: QTBUG-77471
Change-Id: I594ca919c8eca190fa70c6aa84f46f456fcd80e1
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
When running with the threaded render loop of Qt Quick, it could be that
the drawable changes size while the render thread prepares the command
buffer with setViewport and setScissor. Those have no chance to see
such changes, which is normally not a big problem because the resize will
get processed eventually.
However, in debug builds running in XCode, Metal validation checks the
viewport and scissor rects against the (more or less) actual drawable
size, and so would abort Qt Quick apps from time to time when resizing
the window interactively. To solve this, we just query the drawable size
in setViewport/setScissor to keep validation happy.
Change-Id: I451f398bd1f88e3f49ea4624fc45bbb4b70e7f07
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
