Consistently use the same condition to decide whether or not to
set QT_USE_MMAP.
Change-Id: Ica83d40c8051a8957d875334b821037b25fa8677
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QT_USE_MMAP is true only on systems with a defined Q_OS_UNIX,
so there is no need to have code for windows in a section guarded
by QT_USE_MMAP.
Change-Id: I33d4ad596cc96f8f2e41374742fd5ec15b9e91a2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is conceivable that during the try-compare loop of processing
windowing system events we loose and regain the focus. That would
explain the occasional test failure where instead of the expected 3
focus in events, we have received four.
Task-number: QTBUG-77769
Change-Id: I2221440d09a74d4d18a72f7786232b4491cf45a8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit 94902905ec.
The patch caused various test failures on Windows 7 in the CI system in qtdeclarative and qt3d.
Without the patch we ended up using openglsw32.dll, with this patch we get
qt.qpa.gl unknown - supportedRenderers GpuDescription(vendorId=0x0, deviceId=0x0, subSysId=0x0, revision=0, driver: \"\", version=, \"\"\"\") 0 renderer: QFlags(0x8|0x20)
and then end up using ANGLE, which fails.
Change-Id: I97c51f9c360461e1a05722d02d50c2450ca87b78
Task-number: QTBUG-78832
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Cleanup the OpenGL examples
- use nullptr (clang-tidy)
- use member-initialization
- avoid redundant checks for != nullptr when deleting a pointer
Change-Id: I3e4702690ed79e71c3e952d51ceef83b907b45b7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Forcing users to go through a QVector, when in practice they almost
always want to source the data from an initializer list, a QVarLengthArray,
or a plain C array, is not ideal. Especially since we can reason about
the maximum number of elements in the vast majority of use cases for all
the affected lists. QRhiResource is also not copyable so we do not need
the usual machinery offered by containers. So switch to a
QVarLengthArray.
Note that a resource is not a container. The only operations we are
interested in is to be able to source data either via an initializer
list or by iterating on something, and to be able to extract the data,
in case a user wishes to set up another resource based on the existing
one.
In some cases a QVector overload is kept for source compatibility with
other modules (Qt Quick). These may be removed in the future.
Also do a similar QVector->QVarLengthArray change in the srb-related
data in the backends.
Change-Id: I6f5b2ebd8e75416ce0cca0817bb529446a4cb664
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Sad to see this go since the d pointer pattern with implicit sharing
would have been perfect for this class, had this been a public API.
However, as binary compatibility will not be a concern for QRhi classes,
it is wasteful to allocate memory on every QRhiShaderResourceBinding.
This allows users, such as Qt Quick, to use QRhiShaderResourceBinding as
a cheap, simple, value class, without having to invent their own
alternatives in performance critical places.
The change brings a not insignficant improvement in certain qmlbench scenes
(the ones with thousands of unbatched geometry nodes).
Change-Id: I6d1dced6498d9ad625f90ead78bc0a417ea99ed8
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
The expectation for it is to function identically to what we get with
QOpenGLShaderProgram. (same environment variables, same logging
categories, etc.).
QOpenGLProgramBinaryCache is now shared between the QOpenGL convenience
classes (like QOpenGLShaderProgram) and QRhi. To achieve more modularity
and to prepare for QOpenGLShaderProgram and friends moving out of QtGui,
this class cannot depend on QOpenGLShader* anymore. This involves adding
some minor conversions between QRhi and QOpenGL enums for example.
Change-Id: I2f4664e074823ea536281aea8006a6db159a7381
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
One of our compilers for emscripten coerces all signaling NaNs to
quiet ones, so won't do any actual signaling. Anyone relying on them
to do so shall be disappointed, so it's better that they know about it
at compile-time - or, at least, have the ability to find it out.
Put the signaling NaN producers (and remaining (test) code using them)
under the control of a feature that's disabled when numeric_limits
claims double has no signaling NaN. Assume the bootstrap library
doesn't need signaling NaNs. Sadly, until C++20 <bit>, there's no
contexpr way to test that alleged signalling and quiet NaNs are
actually distinct.
Added some auto-tests for signaling NaN, including that it's distinct
from quiet NaN. Any platform on which the last fails should disable
this feature.
Task-number: QTBUG-77967
Change-Id: I57e9d14bfe276732cd313887adc9acc354d88f08
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Revert surfacePixelSize() to be a getter only. With Metal this will
mean returning the "live" layer size (and so not the
layer.drawableSize), which is in line with what we expect with other
backends.
Instead, we leave it to the swapchain's buildOrResize() to "commit"
the size by setting drawableSize on the layer. With typical
application or Qt Quick logic this ensures that layer.drawableSize is
set once and stays static until we get to process the next resize - on
the rendering thread.
This of course would still mean that there was a race when a client
queries surfacePixelSize() to set the depth-stencil buffer size that
is associated with a swapchain. (because that must happen before
calling buildOrResize() according to the current semantics)
That can however be solved in a quite elegant way, it turns out,
because we already have a flag that indicates if a QRhiRenderBuffer is
used in combination with (and only in combination with) a
swapchain. If we simply say that setting the UsedWithSwapChainOnly
flag provides automatic sizing as well (so no setPixelSize() call is
needed), clients can simply get rid of the problematic
surfacePixelSize() query and everything works.
Task-number: QTBUG-78641
Change-Id: Ib1bfc9ef8531bcce033d1f1e5d4d5b4984d6d69f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It can be important to see for example the adapter enumeration that is
printed when qt.rhi.general is enabled. Make it enabled by default in
the tests.
Change-Id: I7bd073781e176d9b17b5386c548e9f8a2e16c10f
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
People implementing D-Bus services *should not* immediately call
QDBusConnection::send() when intending to delay their reply, as this
indeed causes a reply to be sent to the client.
Change-Id: I50817f6b91ac1a02a2a25f6d31e73ad9832f1092
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When a layer is resized, e.g. during a window resize, the contents of
the layer may lag behind if the client doesn't fill the layer in
response to the window resize and corresponding expose event.
The default behavior is for Core Animation to stretch the content
to fill the layer, but this results in the content "jumping" back
and forth when the content then picks up the new size and fills
the layer.
Instead we tell Core Animation to fix the content to the top left
corner. If a layer is sized up without a corresponding layer contents
update this will result in missing/transparent pixels in the bottom
or right part of the layer, explicitly showing what the result of
the missing paint is. During debugging we also highlight this area
by adding a magenta background color to the layer.
Conversely, if the layer is sized down we don't need to resize it,
we can just keep the fixed top left position, and the content will
stay in place during the resize. This allows for optimizations
during window resizing, where we don't need to allocate new
buffers if the old buffer is larger than the new one.
Change-Id: I265b57e3a0ddff8bbcda3af5d670cd8c3b00b181
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We should detect the cases where there's already a delegate, and
setting up the delegate before the layer is added makes sense.
Change-Id: I67896cbc96d11ce9a3826fd8aa0e5e104a83a21c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Change-Id: I29881b379481287b4938e47fc06405c918aa39a3
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It is present in standardPixmap but missing from standardIcon resulting in
QMessageBox using the fallback PNG provided by Qt for the "No" button.
Change-Id: If4f14c7de26eb32277cd19a7be75360dba4f4e29
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Not much different from i.MX6, apart from switching to aarch64 and the
appropriate tune flags.
[ChangeLog][Platform Specific Changes][Linux] Added a device spec for
64-bit i.MX8 systems (Vivante graphics stack)
Change-Id: I1fe939fca87d5f3031cefbf43fa359aeeaf44752
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Change-Id: I077ba12b406f662ba22b2f2cddf0171963335739
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Specify the type of the enum value SendPostedEventsWindowsTimerId
to be UINT_PTR to work with the g++ interpretation of enumeration
signedness and use the correct type for the returned timer id.
Fixes: QTBUG-78491
Change-Id: I7b3f306d3f60da7a21500ece5243ac90854ccf1a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test was found crashing with software rendering in Qt 5.7.
Removing the insignification revealed that there are failures
on WinRT as well, blacklist them for the moment.
Task-number: QTBUG-78802
Fixes: QTBUG-49630
Change-Id: Ib1a3efe69d7b63cdd98c6da364ab09e0e2dbdf62
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
...instead of the qt_ meta catalogs. The qt_ catalogs
are needed for backwards compatibility and depend on
translations for now deprecated modules, such as qtscript,
that might not be installed in the system. This causes
loading the translation to fail.
Instead of the qt_ catalogs, the examples should use the
translation files for the Qt modules used, here qtbase_.
Task-number: QTBUG-69203
Change-Id: I13f5a3d6653cef8379a712fbc02ec320eea4e51a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Various methods were undocumented and even one that was lacked a \since 5.14
Change-Id: I1e65ed1bb9c5b9de06210d7e18af36539aafc4ec
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is a temporary measure to work around an implementation bug on
Integrity: For all other platforms, QtPrivate::condition_variable is
just std::condition_variable. On Integrity, it's a class that wraps
QWaitCondition to provide the interface of std::condition_variable.
This allows the use of std::condition_variable across Qt without
running into the Integrity issue. Once we can depend on an more modern
Integrity toolchain, removing QtPrivate::condition_variable is a
simple mechanical change:
s/QtPrivate::condition_variable/std::condition_variable/g;
s/QtPrivate::mutex/std::mutex/g;
Task-number: QTBUG-78450
Change-Id: I293a99d1cdc48691817b926aa51ecd84556e5e90
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some AMD CPUs (e.g. AMD A4-6250J and AMD Ryzen 3000-series) have a
failing random generation instruction, which always returns
0xffffffff, even when generation was "successful".
This code checks if hardware random generator generates four consecutive
equal numbers. If it does, then we probably have a failing one and
should disable it completely.
Change-Id: I38c87920ca2e8cce4143afbff5e453ce3845d11a
Fixes: QTBUG-69423
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This was visible in the triquadcube test when enabling transparent window
background: the cube on the left was rendered incorrectly because alpha
was not written out due to not setting glColorMask() back to the defaults
when switching to another pipeline.
Change-Id: I7a8c94072e0b68a58fffcc8c1a200e3940dcad44
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
This class will likely be used by the OpenGL backend of QRhi as well.
Therefore, we need to make it more self-contained and independent.
Change-Id: If046ed41e25c70cc9abb45219b451f9179feaa1c
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
This will also cause clearing to 0,0,0,0.
Essential in order to allow fast testing of window transparency
issues in combination with QRhi and the various backends.
Change-Id: Iee2763c1d06f1d3e5d59a9142abaf30fab1dc543
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
With OpenGL a scissor (or viewport) rectangle is not allowed to have a negative
width or height. Everything else is allowed. This is also the semantic we wish to
keep for QRhiViewport and QRhiScissor.
This raises some problems. For instance, when we do bottom-left - top-left
rectangle conversion, the case of partially out of bounds rects needs to be
taken into account.
Otherwise, Qt Quick ends up in wrong scissoring in certain cases, typically when
the QQuickWindow size is decreased so the content does not fit because that will
then start generating negative x, y scissors for clipping (which is perfectly
valid but the QRhi backends need to be able to deal with it)
Then there is the problem of having to clamp width and height carefully, because
some validation layers for some APIs will reject a viewport or scissor with
partially out of bounds rectangles.
To verify all this, add a new manual test, based on the cubemap one. (cubemap was
chosen because that is an ideal test scene as it fills the viewport completely, and
so it is visually straightforward when a scissor rectangle is moving around over it)
Fixes: QTBUG-78702
Change-Id: I60614836432ea9934fc0dbd0ac7e88931f476542
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Since iOS 13, the cascade list for the default UI font contains
meta-families for several writing systems, such as CJK. Since
these font families were never populated to the database, we ignored
them in Qt, and thus got missing glyphs for the characters in question.
The fix is to make sure these fonts are populated in the database.
It contains a partial backport of 922d195020,
which adds the qt_isFamilyPopulated() accessor to allow us to check
if the family has been populated in the font database. In Qt 5.14,
there is public API for this in QPlatformFontDatabase, so this is
a temporary resolution until then.
Fixes: QTBUG-77467
Change-Id: Ia9ebb8a19ad2367eb764ae1496a52966b465336b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
