Now developer build tests compile, but some are not working.
Functional fix will come later via separate tasks.
Task-number: QTBUG-122999
Change-Id: I70487b46c1b32ba4279cb02a4978e4f55ac0d310
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The recent addition of support for multi-frame (non-animation) formats
had an unwanted side effect of sometimes calling
QImageReader::nextImageDelay() when the reader is at a different
frame than intended. Fix by effectively reverting to the previous call
pattern.
Fixes: QTBUG-124227
Pick-to: 6.7 6.5
Change-Id: I735f8d67afb17bd4c77f9b4507a71796b7d66958
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
[ChangeLog][QtGui][QColorSpace] Support for CMYK color spaces has been
added.
Change-Id: I2c684dbeee8b97fc90ca4e2a892349a7fa465d06
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
This also adds image conversion of both format and color space, which
will also be required later for conversions to CMYK formats and color
spaces.
Change-Id: I578c0a010ffcdb4df4cf9080c0621fac8bc342bf
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Follow the established convention that byte-oriented image formats
have the "8888" suffix, not "32". The old enum name is temporarily
left to help port other submodules.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Change-Id: I4b6f10cb22312b614cb9cf4b0ac439907276c538
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
JPEG part 6 defines CMYK support. This commit adds such support to the
JPEG plugin.
A *very* interesting discovery is the fact that Photoshop inverts the
meaning of the CMYK color channels when saving into JPEG: 0 means "full
ink", and 255 means "no ink". Most other image viewers/editors follow
the same interpretation, I imagine for compatibility.
But others, like Adobe Reader, don't (???) -- a PDF expects a DCT
encoding with 0 meaning "no ink". I am adding a SubType to the image I/O
handler to let the user choose what they want, defaulting to Photoshop
behavior.
Also, turns out that Qt was already loading CMYK files and converting
them to RGB. I don't think we should do automatic, lossy conversions (we
were not taking into account an eventual colorspace...), so I'm changing
that loading to yield a CMYK QImage.
Finally: save the colorspace, even if it's a CMYK image.
QColorSpace doesn't support anything but RGB matrix-based colorspaces.
Yet, it can load an arbitrary ICC profile, and will store it even if
it's unable to use it. We can use this fact to preserve the colorspace
embedded in CMYK images, or let users set an arbitrary ICC profile on
them through Qt APIs, and then saving the result in JPEG.
[ChangeLog][QtGui][JPEG] Added support for loading and saving of JPEG
files in 8-bit CMYK format. When loading a CMYK JPEG file, Qt used to
convert it automatically to a RGB image; now instead it's kept as-is.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Change-Id: Ibdbfa16aa35814f5dba28c2df89577175162b731
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
This commit adds a CMYK 8bpp format to QImage. The idea is to enable the
transport of CMYK images inside Qt, for instance to be loaded/saved from
files or painted on CMYK capable paint devices (e.g. PDF).
Also, rasterization support *from* a CMYK image is added (on top of a
RGB surface), as well as CMYK image scaling/conversion.
Conversion and rasterization between CMYK and RGB isn't particularly
optimized nor it honors any colorspaces yet. The overall idea is to
match 1:1 the existing behavior of CMYK QColor (which get naively
changed to RGB; there isn't colorspace support in QPainter yet).
There are no plans to add rasterization *towards* CMYK.
Image save/load in native CMYK formats will be added in future commits.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
[ChangeLog][QtGui] Support for 8-bit CMYK images has been added.
Change-Id: I4b024cd4c15119c669b6ddd450418a9e425587f8
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Wrap the call in QVERIFY.
tst_QTextStream::read0d0d0a was also faulty as it *never* opened
the file because of a broken path. Fix it with QFINDTESTDATA.
Change-Id: I61a8f83beddf098d37fda13cb3bfb4aaa4913fc5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In 4c21f72837 we did this for
QImageReader. So, to support the same for QMovie, we just need
to remove the custom (and very inefficient) scaling for frames.
This should be safe since the underlying QImageReader must ensure
that the returned image matches the scaled size.
[ChangeLog][QtGui][QMovie] Allow only one dimension (width
or height) to be set for the scaled size. In this case, the other
will be calculated automatically based on the original movie size
and maintaining the aspect ratio.
Fixes: QTBUG-115039
Change-Id: I50979a75970c79647dbb8c8b4b121266ba033a63
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
If only one dimension (width or height) of the scaled size is set
by an user, let's try to calculate the second one, based on the
image original size and maintaining the aspect ratio.
[ChangeLog][QtGui][QImageReader] Allow only one dimension (width
or height) to be set for the scaled size. In this case, the other
will be calculated automatically based on the original image size
and maintaining the aspect ratio.
Task-number: QTBUG-115039
Change-Id: If1b13b1ead3cf788915c08bdb3ba8becd8bf8042
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
QtIcoHandler::canRead() calls ICOReader::canRead(), which assumes that
QIODevice::pos() is at the position where the .ico data starts (i.e.
pos() == 0 if this is a separate .ico file). But if an AnimatedImage in
Qt Quick opens an .ico file, canRead() gets called multiple times:
the first is when QQuickAnimatedImage::frameCount() eventually results
in QImageReaderPrivate::initHandler(); then ICOReader::readHeader()
is called, which moves the file position. The second time is when
QQuickAnimatedImage calls QMovie::isValid(). At that time,
QIODevice::pos() == 6: we need to avoid calling ICOReader::canRead()
because it's no longer at the start of the data.
Without this change, AnimatedImage reports "Error Reading Animated Image
File" and doesn't show anything.
The fix is to store the known-good state, the same way that
QTiffHandler::canRead() returns true if its d->tiff already exists
(TIFFClientOpen() succeeded).
The test checks that it's ok to call QMovie::frameCount() first and then
QMovie::isValid(). Calling frameCount() has the effect of moving
QIODevice::pos().
Pick-to: 6.5 6.6 6.7
Task-number: QTBUG-117429
Change-Id: Ie3a5225f2cea9a0d76d685e83ce4d4a10cbe9188
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Since 3f4d6279c4b0d04422efff478a5e2fb36259dbaa (khansen 2005) QMovie
calls QImageReader::read() until QImageReader::canRead() returns false.
That's apparently to support animated image formats in which the
frame count is not known at the beginnning (i.e. not specified in
the image format's metadata). But non-animated multi-frame formats
are expected to return valid values from QImageReader::imageCount();
and those also tend to keep returning true from canRead() regardless
of how many frames have been read (the interpretation of canRead()
is "does the file have the expected format?" rather than "are we
about to read too many frames?"). So, when a multi-frame image is abused
as an animation, QMovie was able to keep reading the same frame
repeatedly and pretend that the frame sequence goes on forever.
It also tended to read frames as fast as they could be decoded,
because nextImageDelay() is not usually provided, because multi-frame
image formats don't specify a frame rate in their metadata.
So now we change QMovie's behavior for image formats where
QImageIOHandler::supportsOption(Animation) returns false:
trust imageCount(), but not do not trust nextImageDelay().
But to actually jump to the next frame in this case, we also need to
call QImageReader::jumpToNextImage().
Altogether, this makes QMovie support "flipbook" animation for
multi-frame image formats, such as tiff and pdf.
Added "read frame x of c" logging in qt.gui.imageio category.
For testing, we use a pre-existing multi-frame Obj_N2_Internal_Mem.ico
file, to avoid depending on the tiff plugin.
[ChangeLog][QtGui][QMovie] QMovie now handles non-animated multi-frame
image formats (such as tiff): QImageIOHandler::imageCount() is observed,
and the default frame rate is 1 FPS.
Pick-to: 6.5 6.6 6.7
Fixes: QTBUG-117429
Change-Id: I6dad2a684e12c78a68288402e223a59427bf649e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
A copy without pixel ratio was made, but color table not set.
Pick-to: 6.7 6.6 6.5 6.2
Fixes: QTBUG-119902
Change-Id: I328f3faa70d7a1263061cbe51921999393e30801
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
... instead of just choosing the closest scaling factor.
Otherwise we end up with the 1x pixmap for a 1.25 scaling factor instead
of a the better fitting 2x pixmap.
Task-number: QTBUG-90634
Change-Id: Ic554fc8d2715deea43bc22e71414902a263b2fef
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Makes it possible to add new unpremultiplied formats later.
Change-Id: Id998a2674ca9067a0e2a5f85c7baf04bcd9a9912
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Add a list of constant string literals for a subset of icons from the
freedesktop specification. Those are icons we document to support today,
and that users might have written themes for.
Omit icons that are mime types (we have Q(Abstract)FileIconProvider
and QPlatformTheme::fileIcon for that), the "flag-aa" icon (where 'aa'
is an ISO 3166 country code, and Face* icons. Flags and Face icons can
be added as supported QIcon constants, but should then be rendered as
emojis from the respective font (they are not provided by any of the
native icon libraries or icon fonts).
We use string constants instead of an enum so that we have the same code
path for icon constants, user-defined icons, and native icons. I.e. in
addition to QIcon::fromTheme(QIcon::ThemeIcon::EditCopy), code can
request the icon for "trash.circle.fill" on Apple platforms, or
or for U"\ue5cd" on platforms where the engine is font-based; or an app
can define their own icon name and provide the assets through a theme-
description, as before.
The downside is that we cannot use arrays for looking up the native icon
for an enum-value in the engine implementations, but given that icons
are cached this is an acceptable trade-off.
To make the list of icon contants more manageable, have them in a
separate header file. Since we want those constants to live in the QIcon
"namespace", we then include that header in a declaration of a nested
struct, "ThemeIcon", resulting in e.g. QIcon::ThemeIcon::EditCopy.
Change-Id: Ic20e36ab321e6c4b20806ec0b400bba13fffc983
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If a QPA-provided engine provides an "edit-cut" icon, then it won't be
null. We cannot reliably test that the icon came from the fallback theme
as the cacheKey of the icon doesn't change (the proxying to a different
theme is handled internally by the QThemeIconEngine).
That the cacheKey of a QIcon doesn't change even if the pixmaps we get
from it change is not a problem in practice; QIcon is a named container
for transient graphical assets that might change for reasons outside of
Qt's control (such as color scheme, or display resolution).
Change-Id: I695e8ad0c8f0aec7f17a2c242e64b615178b78b5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The ppm spec allows 1-bit ascii ppm files to have no spaces bitween the
single bits. Therefore we have to adjust read_pbm_int() to stop after
reading one digit.
Pick-to: 6.6
Fixes: QTBUG-119239
Change-Id: I161038076c5dee4662aa66a1215822fc75e6a19e
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reimplement the virtual function QIconEngine::isNull() for
QPixmapIconEngine. This lets QIcon::isNull() return true when no pixmaps
are loaded during QIcon::addFile() e.g. due to a wrong filename.
Pick-to: 6.6 6.5
Fixes: QTBUG-118667
Change-Id: I29f2c492e55b60638507fa398ef7af76f4e9ff48
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The old tests were not using the test methods from QTestPrivate, so
add another test case.
Task-number: QTBUG-116346
Pick-to: 6.6 6.5
Change-Id: I291ede26461e79a615630f1decad2ad7549b4dd8
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Other recent commits have fixed the other Q_FOREACH uses in this file.
Task-number: QTBUG-115839
Change-Id: I03063f3e8f1e99c5a2aa2d9188260f3e79ca43bd
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The density of Q_FOREACH uses in this and some other modules is still
extremely high, too high for anyone to tackle in a short amount of
time. Even if they're not concentrated in just a few TUs, we need to
make progress on a global QT_NO_FOREACH default, so grab the nettle
and stick to our strategy:
Mark the whole of Qt with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).
In tst_qglobal.cpp and tst_qcollections.cpp change the comment on the
#undef QT_NO_FOREACH to indicate that these actually test the macro.
Task-number: QTBUG-115839
Change-Id: Iecc444eb7d43d7e4d037f6e155abe0e14a00a5d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Instead of copying a list, sorting it just to check it's sorted, and
making a QSet out of it just to check the size is the same as that of
the list (thereby checking there were no duplicates), simply apply
adjacent_find with greater_equal. If none of the elements is ≥ their
successor, that means all elements are < their successor, and _that_
means the range is sorted and has no duplicates. q.e.d.
Pick-to: 6.6 6.5
Change-Id: Id73c674ad4e29117370e8fc6af9fdfc690a3fba9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The following commits neglected to amend
tst_QImageReader::supportsOption() with the ImageOption enumerators
they added to QImageIOHandler:
- c0ba249a48
- 163af2cf53
- ba323b04cd
Fix first and foremost by adding the missing ImageOption::ImageFormat
to the list of PNG-supported formats (which, curiously enough, predates
the public history and therefore the above three commits), and second,
by rewriting the whole test function to enable -Wswitch, so further
additions are less likely to be forgotten.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I102121b2c8a9067864b8ade2ebe2650be6fb6010
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I40773a0397b83cce0c803967ee3fd7ae274933d3
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Amends a452e22546. No new tests, existing
tests fails when QPlatformTheme returns a QIconEngine implementation
that provides the tested icons. However, the existing test fails when
the platform icon engine provides and address-book-new icon, and depends
on the order of test functions, as the name() test function modifies the
global theme name and search path. Fix those issues in the test.
Pick-to: 6.6
Change-Id: Ie1c1d14f08fad5e906296bab662df5cfacdbbf07
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
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>
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>
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>
It causes clashes in CMake Unity (Jumbo) builds.
Change the function to be Q_AUTOTEST_EXPORT'ed helpers.
Pick-to: 6.5
Task-number: QTBUG-109394
Initial-patch-by: Amir Masoud Abdol <amir.abdol@qt.io>
Change-Id: I2e4032e07e1c39432cae1eb2dfff94be33846c09
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is inherently faster than getting it in UTC from the underlying
native API stat call, then converting it to the Local Time Zone just to
compare them. The same goes for any use-case where you get a QDateTime
then the first thing you do is call t.to{Msec,Secs}SinceEpoch().
Change-Id: Ic13bcfd99b937c9f10f102ea7741832950a553c6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to
handle typedefs and accesses through pointers, too:
const std::string o = "object";
auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); };
auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) {
auto exprOfDeclaredType = [&](auto decl) {
return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o);
};
return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))));
};
auto renameMethod = [&] (ArrayRef<StringRef> classes,
StringRef from, StringRef to) {
return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)),
callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))),
changeTo(cat(access(o, cat(to)), "()")),
cat("use '", to, "' instead of '", from, "'"));
};
renameMethod(<classes>, "count", "size");
renameMethod(<classes>, "length", "size");
except that the on() matcher has been replaced by one that doesn't
ignoreParens().
a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'.
Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache,
to avoid porting calls that explicitly test count().
Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Two rows shared a data tag. Prefixed one of them with the color of the
half-transparent image it involves (the other's is fully transparent).
Change-Id: I1bd174008ed29bcf2f460e683fdf6d1f12ba19d0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The same data tags were used with two distinct filenames in their
data. Include the basename of each filename in the data tag, to avoid
duplication.
Change-Id: I216fecbd413fab409227ad6f93f8ac3fcc74b059
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Jari Helaakoski
Eirik Aavitsland
Allan Sandfeld Jensen
Giuseppe D'Angelo
Vladimir Belyavsky
Shawn Rutledge
Tasuku Suzuki
Lucie Gérard
David Schulz
Volker Hilsheimer
Christian Ehrlicher
Joni Poikelin
Ivan Solovev
Marc Mutz
John Chadwick
Alexandru Croitor
Tor Arne Vestbø
Liang Qi
Friedemann Kleint
Ahmad Samir
Edward Welbourne