As a result of the fix for QTBUG-75214, Qt inadvertently no longer
reads the AND mask that specifies transparency for 16-bit and 24-bit
ico files. This is because it tries to detect 32-bit icons by checking
icoAttrib.depth == 32, but icoAttrib.depth is set to the depth of the
QImage, not the depth of the icon, and 32-bit QImage is used for all of
the non-indexed cases (16-bit, 24-bit and 32-bit.)
This commit instead uses icoAttrib.nbits, which should reliably
determine whether or not the icon is 32-bit. This makes the behavior
consistent with other ico reading software, including Windows.
Also, adds a unit test that verifies correct behavior of icon masks,
checking for both QTBUG-75214 and QTBUG-113319.
Amends 1d128ed1df.
Fixes: QTBUG-113319
Change-Id: I89ac86ff16054c8925fff6afc8c530fa737f8385
Pick-to: 6.6 6.5 6.2 5.15
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Add the boilerplate standalone test prelude to each test, so that they
can be opened with an IDE without the qt-cmake-standalone-test script,
but directly with qt-cmake or cmake.
Boilerplate was added using the following scripts:
https://git.qt.io/alcroito/cmake_refactor
Manual adjustments were made where the code was inserted in the wrong
location.
Task-number: QTBUG-93020
Change-Id: I2ef59684cf297a0222a136ce7b5630037294d000
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To maintain flexibility in how we store the features, we
introduce accessors through indirection rather than accessing
the property directly.
Made as response to API review.
Pick-to: 6.6
Change-Id: I3e5d4ddabe93f67796af4626fddefe028ded9888
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
It's not a real leak in that the string data is being freed on program
exit (or, more recently, QPixmapCache::clear()), but it can lead to
lots of memory being bound for much longer than expected when users
put in new QString keys without attempting to retrive them again. It
can also lead to problems with QStringLiterals lingering around until
after their underlying data has been freed. A bug in the Fusion style,
generating new string keys for identical state, exposed this
misbehavior, and one way to fix the resulting issue for the user is to
make sure that QPixmapCache doesn't leak QString keys.
The Fusion style issue with generating non-repeating keys for use with
QPixmapCache should also be fixed, eventually, but this patch
relegates that to an optimization issue (the caching is effectively
non-existent), the resource exhaustion is gone now.
The issue exists because the QString keys are internally mapped to
QPixmapCache::Key's by way of a QHash<QString, Key> cacheKeys data
structure. When the QCache, indexed by Key, not QString, decides to
evict an entry, the Key is invalidated, but no-one was removing the
corresponding entry from cacheKeys. So make the existing releaseKey(),
used to invalidate copies of Keys referring to evicted pixmaps, do
that, now. So as not to have to scan the whole cacheKeys QHash for the
right Key, store the QString key, if any, inside the Key, so
releaseKey() can retrieve it and use it for O(1) erasure from
cacheKey.
This allows removing the previous work-around in clear()
(6ab0d25a09), greatly simplify
object(QString), and requires to rewrite all code that holds iterators
or references into cacheKeys over an insertion into or removal from
the QCache. Two (insert() and remove()) have already been done in
prequel commits, so only flushDetachedPixmaps() was left.
Fixes: QTBUG-112200
Pick-to: 6.6 6.5
Change-Id: Ic93b0ed388ae963267fe242b491c6c941d146b99
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We still need to consult fallbackThemeName() when computing the
parent list for an individual theme, as the Freedesktop Theme Icon
spec mandates that the "hicolor" theme comes last, but we no longer
need to do explicit fallback to fallbackThemeName() if a theme is
not found.
Pick-to: 6.5 6.6
Change-Id: I6c0b5a45d8258c5b6eaa761402944a735b1606ba
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The use of fallback icons should not depend on a theme being set.
[ChangeLog][QtGui][QIcon] QIcon::fallbackSearchPaths() will now be consulted
for fallback icons even if the current theme name is empty.
Pick-to: 6.5 6.6
Change-Id: Ia8d14062de7c53601fd9dac30f87a9e672aa2207
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We would previously only use the fallback theme for themes that did
not exist, or for themes that did not declare any parent theme.
We now unconditionally use the fallback theme, even for themes that
declare their own parent themes, so that a QIcon::fromTheme("foo")
that doesn't exist in the current theme, nor any of its parents,
nor in "hicolor", will still be looked up in the fallback theme.
The reason this seemed to work in the existing tests was because
our test themes inherit system themes such as crystalsvg and gnome,
and we didn't provide a hicolor theme. Any of these themes missing
would lead us into the code path where we use the fallback theme
for a missing theme, masking that fact that we had not added the
fallback theme to the list of fallbacks for the theme that had
explicit parents declared.
The logic has been moved out of the theme parsing and into an
accessor in QIconTheme, so that we're not caching the fallback
theme lookup.
[ChangeLog][QtGui][QIcon] QIcon::fallbackThemeName() will now be
used as fallback even for themes that declare a parent theme.
Pick-to: 6.5 6.6
Change-Id: Ib0ce1dfe97030f23893460ed624073a719a3ebd1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Setting a fallback theme will affect the lookup strategy, so we need
to invalidate earlier lookups.
Pick-to: 6.5 6.6
Change-Id: I962245ddb3a20b7798d5ce831ed8a369b0ab76b4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The replace() implementation overwrites the passed Key key with a new
version, const_cast'ing away the const from the key passed by
reference-to-const. This is UB if the Key was originally declared
const.
Deprecate the function.
Also inline the const_cast, so compilers can readily detect the UB
even if users don't enable deprecation warnings. Due to the severity
of the issue (UB), immediate deprecation is warranted. There appear to
be no in-tree user of the API outside of tst_qpixmapcache.cpp.
[ChangeLog][Deprecation Notice][QtGui][QPixmapCache] The `replace(key,
pixmap)` function has been deprecated, because passing a `const Key`
to it results in undefined behavior. Use `remove(key, pixmap)`
followed by `key = insert(pixmap)` instead.
Pick-to: 6.6
Change-Id: Ic5060ce3271f2a1b6dc561da8716b452a2355d4c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QDeferredDeleteEvent has the loopLevel field, which is a sum of
scope and loop levels found at posting. In sendPostedEvents however,
it is impossible to only use this information to find delete events
posted before the outermost loop (which should be handled by any loop)
based solely on this information, as the scope level essentialy removes
the information on loop level.
Break the loopLevel in two, storing both loop and scope levels in
QDeferredDeleteEvent, so that we can check whether an event was posted
before the outermost event loop (for which we need to compare only the
loop level).
QDeferredDeleteEvent was also made private as it should - it is an
implementation detail that wasn't hidden properly.
Change-Id: I0a607a0bd3a2deb5024acad67f740dbf4338574c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Between the find() == 0 obfuscation (since fixed) and this unchecked
replace(), it took me way too much time to figure out what was going
on: the key passed has been invalidated by the setCacheLimit(0).
Now that we QVERIFY that the replace() _fails_, it's much easier to
backtrack and figure out why it does so and why, consequently, the
following find() is also expected to fail.
As a drive-by, reorder two lines so the grouping becomes clearer
(blocks now both headed by setCacheLimit()).
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I434b65fc13c3fed6512036efeb98d738eeb2a13d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
None of the existing tests failed when I started to return a valid key
from a failed insert(QPixmap), so add a test that would fail.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I74f23d2ec4c04151f8f1266c0c503713d4642f3a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is just confusing. QPixmapCache::find() already returns bool,
comparing it to a literal zero just makes it hard to read.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I43c000890377cca2111daa48799f10cc99aad8cf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QPixmapCache maintains a mapping from QString to QPixmapCache::Key, in
the form of the cacheKeys QHash, but QPixmapCache::clear() didn't
touch it, leading to the string data (as well as the Keys) being
retained after any possible use. This can lead to memory slowly being
eaten up, as reported in QTBUG-112200, and prevents a periodic calling
of QPixmapCache::clear() from being a work-around for the issue in the
bug report.
Fix by clearing cacheKeys in QPixmapCache::clear().
This is designed as a low-risk enabler of a work-around, not a fix for
the issue. The work-around enabled by this is periodic calling of
QPixmapCache::clear().
[ChangeLog][QtGui][QPixmapCache] Fixed QString key data not being
freed on clear().
Pick-to: 6.6 6.5 6.2 5.15
Task-number: QTBUG-112200
Change-Id: Ica6fa0e27e1b47b8df58d5e996378a2ececa5f9c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The desktop file name should not contain ".desktop" suffix, but some
applications still specify it anyway because of the ambiguity in the
documentation that was fixed in
0c5135a9df.
This change makes setDesktopFileName remove ".desktop" suffix so
desktopFileName always returns a desktop file name with correct format
and its users don't need to chop ".desktop".
Pick-to: 6.5
Change-Id: If5abccaf3bf976449cada8891fff887870e45b5f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Mainly for completeness, but it has practical uses: someone retrieving
a QRhi instance from somewhere should be able to tell the
QVulkanInstance, and so the VkInstance, used by that QRhi without
resorting to investigating other objects (e.g. retrieving the instance
from the QWindow). This provides symmetry to other 3D APIs and QRhi
backends where just a single QRhi instance is sufficient to get the
MTLDevice, ID3D11Device/Context, etc. i.e. all that is needed to
work with the 3D API directly.
Change-Id: I5a8b9871a543ea648c76b868bf6ff7be5f2098f2
Reviewed-by: Jonas Karlsson <jonas.karlsson@qt.io>
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
This test fails too frequently on Android and RHEL to leave in as
significant. The bug report is already closed after timeouts were
extended, so perhaps we just have to accept the status quo. No
point in keeping tickets open for tests that we can't get stable on
some platforms.
Pick-to: 6.5
Task-number: QTBUG-102239
Change-Id: I54b8ae821e93b3e1f24acd67a2e84ef405388667
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The color role AccentColor has been added to QPalette.
This patch implements the new color role in QCssParser and subsequently
in QStyleSheetStyle.
The QBrush variable names used to populate brushes, have been changed
into speaking names for better code readability.
tst_QCssParser has been adapted accordingly.
The test function accentColor() has been added in tst_QStyleSheetStyle.
Documentation has been updated.
Change-Id: Ib09ddc1b61868f2bb8f70f654e83ea1c35276d30
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It is necessary to add an AccentColor role to QPalette.
QPalette currently has 21 color roles and 3 color groups, which
require 63 bits to resolve. The resolve mask is implemented with a
qint64, which doesn't provide spare bits for another color role.
The color role NoRole is used as a default value, marking that a role
has not (yet) been defined. The enum value does not represent a valid
brush, even though it can theoretically be stored in QPalette's shared
data.
This patch adds the enum value AccentColor to QPalette::ColorRole,
increasing the available color roles to 22.
To keep the resolve mask at 63 bits, AccentColor is mapped to NoRole
in static constexpr bitPosition.
As the enum range would exceed 64 bits without this tweak, 3 additional
bits are substracted in the respective static assertion.
With NoRole having no bit in the resolve mask, the following adaptions
have been implemented:
- QPalette::resolve() is adapted to explicitly ignore NoRole.
- QPalette::isBrushSet() always returns false for NoRole.
- tst_QPalette::setAllPossibleBrushes() to verify the latter
- operator== ignores NoRole (documentation updated)
AccentColor is added in tst_QPalette::roleValues and enum documentation
is adapted.
In QPalette's default constructor, the AccentColor brush is defaulting
to the Highlight brush, it this is available. Otherwise it is made 30%
darker or lighter than the Base brush, depending on dark/light mode
heuristics.
QPalette's data stram functions have been extended from QDataStream
Version Qt_6_6. If earlier versions are de-serialised, the AccentColor
defaults to Highlight. An autotest function dataStream() has been added
to tst_QPalette.
The QDataStream Version Qt_6_6 has been bumped to 21.
tst_QDataStream has been adapted to the new version and the new
color Role.
Change-Id: I98bbf9de95fb83bda921e9614a0db3a3c0ebdf75
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from
shadertools; done separately) become "RHI APIs", following the concept
of QPA APIs.
Mirror completely what is done for QPA headers, but using the "rhi"
prefix for the headers. This involves updating syncqt to handle the
new category of headers. (a note on the regex: matching everything
starting with "qrhi" is not acceptable due to incorrectly matching
existing and future headers, hence specifying the four header names
explicitly)
There is going to be one difference to QPA: the documentation for
everything RHI is going to be public and part of the regular docs, not
hidden with \internal.
In addition to the header renaming and adding the comments and
documentation notes and warnings, there is one significant change
here: there is no longer a need to do API-specific includes, such as
qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a
single header that is then included from qrhi.h. This means that users
within Qt, and any future applications can just do #include
<rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no
other headers are needed.
There are no changes to functionality in this patch. Only the
documentation is expanded, quite a lot, to eliminate all qdoc warnings
and make the generated API docs complete. An example, with a quite
extensive doc page is added as well.
Task-number: QTBUG-113331
Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Use qUtf16Printable() to convert QString to somthing consumable by
%ls. Fixes the format/argument mismatch on non-Windows platforms:
tst_qfont.cpp: In member function ‘void tst_QFont::italicOblique()’:
tst_qfont.cpp:153:67: warning: format ‘%ls’ expects argument of type ‘wchar_t*’, but argument 2 has type ‘const ushort*’ {aka ‘const short unsigned int*’} [-Wformat=]
153 | QVERIFY2(f.italic(), qPrintable(QString::asprintf("Failed for font \"%ls\"", f.family().utf16())));
| ^~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
| |
| const ushort* {aka const short unsigned int*}
Amends 4bf82909f1.
Change-Id: I0c7e2dca91a093835d7dba8bff2e5ea78d3a926e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It fails locally for me on Lucida Calligraphy.
Lucida Calligraphy only has one style though: Italic.
Change-Id: I42442cb922132a00f09084cef9c739196a9a53c2
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Exercise the validity of update batches, i.e. that one can
safely commit it in later frames as well, as long as all
related buffers and textures stay valid.
Change-Id: Ia943e4b37141fe17253eeae32010e0f8d92c1583
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
These classes depend only on Core, not Gui.
This allows dropping the dependency of tst_qxmlstream and tst_qzip on
QtGui, and prevents a tst_qxmlstream FTBFS when building with
QT_NO_TEXTODFWRITER.
Symbols move from QtGui to QtCore, but the classes are private API, so
not under BC constraints.
The classes are not used outside qtbase, so no other in-tree users
need porting.
Task-number: QTBUG-3897
Change-Id: Ifa148f43ec139d7f9ac1f3893e2fcf4640e3c60c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qtbase/c27d2a57a441f9a1ce760e71635bd4c96882249d caused the code
to go through QStandardItemPrivate::setItemData() which does
not handle the special treatment of Qt::EditRole completely.
In the constructor of QStandardItemData; map Qt::EditRole to
Qt::DisplayRole to fix this as is done in setData().
Adapt the existing tst_QStandardItemModel::getSetItemData() to check
whether both roles are received in the dataChanged() signal.
Pick-to: 6.5
Fixes: QTBUG-112326
Change-Id: I133d058bacc3388c612c5b4fb18b54f5ef5cb56f
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: David Faure <david.faure@kdab.com>
...even when the QRhi is already gone. This should not happen in
well-written applications and libraries, but we handle this
gracefully in the regular dtor and destroy() for resources that
register themselves to their creator QRhi, so by registering
everything we can offer this to all QRhiResource subclasses.
We still want to differentiate between native resource owning
QRhiResources and others (that do not create native graphics
objects), so do this via a flag passed to registerResource().
This way the behavior with QT_RHI_LEAK_CHECK=1 does not change.
Pick-to: 6.5
Fixes: QTBUG-112914
Change-Id: I9bafc81ef7a4ae76f356fc5f6248628d1f8791e0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Equivalent to the test added to the QWidget test case, but since QtWidgets
code contains logic to both synthesize and compress/filter enter/leave
events, we can only verify that the QWindow does get the events.
The test is very flaky on Windows, so blacklisting it right away.
Change-Id: Ic1da9439f60f619a76a3653a23fef8e9ebc0e75d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We sometimes use Objective-C++ code in files with a .cpp extension,
to avoid the churn of adding a foo_mac.mm file. Instead of manually
telling the compiler to build these files in Objective-C++ mode, we
use CMake's intended mechanism, which means genex constructs such as
$<$<COMPILE_LANGUAGE:OBJCXX> will work for these files as well.
Pick-to: 6.5 6.2
Change-Id: If295c3f34f6bee9f4d9f877f519c9c7770665fee
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We can expand the testing a bit bit verifying that also
created windows work as expected, and that QWindow DPR
is updated when Screen DPI is changed.
Change-Id: I082aac18b6b086c69c16681977b7eaa6c3e54ee0
Reviewed-by: Jukka Jokiniva <jukka.jokiniva@qt.io>
A foreign window can be used both for embedding a Qt window into a
native window hierarchy, or for embedding a native window into a Qt
window hierarchy. In the former case, we should not modify the foreign
window in any way. Since the platform does not know anything about the
intended use case at the time of the foreign window creation, it should
avoid modifying the foreign window in any way, and should instead pick
up the foreign window state and reflect that through QWindow.
Pick-to: 6.5
Change-Id: Id2e39d101277ecebd656d615cea3e7f734a4b0a6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QT_SCREEN_SCALE_FACTORS is in many cases set on behalf of the user,
instead of by the user, so we should apply the standard app
scale factor policies to it, instead of interpreting it
as a user override.
Specifically, make it subject to the rounding policy set by
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(). This
means that applications which support integer scale factors
only will see integers only, also when QT_SCREEN_SCALE_FACTORS
specifies a fractional factor.
Users who want to override can set
QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough
to restore the default Qt rounding behavior.
[ChangeLog][QtGui] The high-DPI scale factor rounding policy (settable with
QGuiApplication::setHighDpiScaleFactorRoundingPolicy() or
QT_SCALE_FACTOR_ROUNDING_POLICY) now applies to scale factors set
with QT_SCREEN_SCALE_FACTORS.
Fixes: QTBUG-95930
Fixes: QTBUG-99546
Change-Id: I936e96671fe2a0a43c3e8129f0768875cb011103
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The necessary QT_ENABLE_P0846_SEMANTICS_FOR is already provided by
qpoint.h) here. Add a test to confirm it works.
Amends 0e22001a3b.
[ChangeLog][QtGui][QVector2/3/4D] Fixed manual get<I>() calls
(Tuple Protocol) in C++17 mode.
Task-number: QTBUG-111598
Change-Id: Id4a118b6439c2d1471b921f8d92ee558f9902eab
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is useful for a lot of applications that render text coming from
sources which already support arbitrarily numbered lists (like chat
applications for example). Application-side workarounds usually have
significant overhead; and this feature has been requested multiple times.
It should be possible to both read and write HTML with the <ol start="x">
attribute, and read and write Markdown with arbitrary numbers for the
first item in a list.
[ChangeLog][QtGui] QTextList now supports specifying a start index using
the new QTextList::{setStart, start} functions. The HTML start attribute
on ordered lists in rich text documents is now parsed and used when
rendering a text list. Non-negative indices in markdown lists are now
also parsed and written properly. This allows starting a list with a
different number than 1.
Fixes: QTBUG-30407
Fixes: QTBUG-65384
Task-number: QTBUG-107562
Change-Id: Ib35b9378d9134ffedaa2d92f728b0984793aa7c1
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This is expected to be temporary and to be investigated afterwards.
Task-number: QTBUG-108844
Pick-to: 6.5
Change-Id: I0a571dad2b99ceaa0fd48e5cdd81057e49e55ddf
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Amends 76c63936d3 by adjusting the test case.
We still just test that we can open a file based on a filename that we came
up with ourselves.
Also, update usage documentation and make the snippet a bit more relevant.
Change-Id: I5bf00210d74e2a73d5a71a09a5beb1b3f6f8e225
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Add support for shader input output interface blocks in Metal
tessellation pipelines. This feature is builtin to other rhi supported
tessellation backends (OpenGL/Vulkan).
Metal tessellation is implemented as compute pipelines for vert and
tesc, and a render pipeline for tese and frag. The shader conversion
from GLSL is handled by SPIRV-Cross, which has a particular way of doing
things. Rhi must setup the vertex inputs for the tese - frag render
pipeline to read from buffers written by the tesc compute pipeline,
following SPIRV-Cross conventions. This includes ensuring correct
memory alignment per MSL Specification.
In order to enable input output interface blocks, reflection of struct
members of QShaderDescription::InOutVariable is required. Reflection of
QShaderDescription::BuiltinVariable array dimensions is also required to
support variable size tese builtin input gl_ClipDistance.
An acompanying patch to QtShaderTools is required.
Change-Id: Id94e86caef211485afc187bb79fe3d0619d02cf0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Not relevant for the CI as that does not run with any real Vulkan
implementation. (and Lavapipe works if that's used)
As the investigation in the Jira issue shows, there is no proper
conclusion yet on why rendering to a slice of a 3D texture breaks
the content of other slices that have image data written to them
before that render pass targeting the slice. It would seem that
transitioning to COLOR_ATTACHMENT_OPTIMAL has some unexpected
consequences for slices that are not targeted by the render pass
with Mesa on Intel.
(NB rendering to a given 3D texture slice works via
VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT; and how often this is needed
in practice is unclear, typical volume rendering cases will anyway
likely just upload data to the slices of a 3D texture, not rendering
to them)
The problem is still clearly visible in the tex3d manual test (when run
on affected Linux machines), this we keep unchanged for the time being
so that the issue can be examined further. However, the autotest is
changed to prevent the issue from occurring (render to slice first,
then upload to other slices) since it causes confusion when the test
is run locally on various developer machines.
Pick-to: 6.5
Task-number: QTBUG-111772
Change-Id: I4dc4c2413f8c518f377a33065992ad786a5ff44f
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Separate 1D mipmap generation support from rendering into an 1D texture.
Those are two independent features, so have a separate feature flag for
both instead of using just one.
This will then be symmetric with the 3D texture features, where now we
have a new flag to report support for generating mipmap for 3D textures.
(whereas 3D texture as a render target is already covered by
RenderTo3DTextureSlice)
Change-Id: Ie5e1f056a7d1c341d90cd7fc522877a3f2da3290
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Use a scope guard to print debug info in case of an early return.
Silences clang warning about sprintf being unsafe and deprecated.
Change-Id: Idcbfde1a6f2eb1143f51c1e5ecedbf3fe90d8ec8
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The doc said positive values for a negative range were intermediate
but the code actually rejects them if the value has an overt plus
sign, so make clear that intermediate is only for the case without a
sign. Incidentally comment on a test where it might not have been
obvious to the reader that a space is the locale's digit-grouping
chracter.
Pick-to: 6.5 6.5.0
Change-Id: I3edab74fe8c2cbe8448c0e523676f1fd0d0d8a9f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
