This time exercising series of buffer updates and texture uploads
within proper, on-screen frames. (particularly interesting for dynamic
buffers in case the double (or more) buffering and having multiple
frames in flight involves special bookkeeping for these - using
'offscreen' frames like in other test cases does not necessarily
exercise all of this)
Change-Id: Id470919d27037359a1f0346a50a2a0e3966f5cd2
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
We have some special handling in qt_windows.h,
use it instead of the original windows.h
Change-Id: I12fa45b09d3f2aad355573dce45861d7d28e1d77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Amends 4dd5020fbdfdd34f1e4ec54521217e472942a4b4. I messed up the fix for
the XFAIL condition, since the font engine type we get from a normal QFont
will be QFontEngine::Multi regardless of whether the actual font engines
are Freetype or not. Use NoFontMerging to avoid this.
Pick-to: 6.2
Task-number: QTBUG-97995
Change-Id: I2298c997e6826e667dbb8e3d004821f296625ef7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
In Qt 5, fonts had both singular family and plural families properties,
and both were stored separately when streaming through QDataStream. The
families list was treated as an extension of family in this case, and
the primary font family was always the singular family property.
In Qt 6, it has been merged into one and family() is now just a
convenience for families().at(0).
But when reading files generated with Qt 5, we would ignore the fact
that these were previously separated. We would first read the family
entry into the families list, and then we would later overwrite this
with an empty families list.
Instead, we detect streams created with Qt 5.15 or lower and make sure
we append the families list instead of overwriting it in this case. In
addition, we need to make sure we split up the list again when
outputting to Qt 5.x.
This adds a file generated with QDataStream in Qt 5.15 to the test to
verify.
[ChangeLog][Fonts] Fixed a problem deserializing the family of fonts
that had been serialized using QDataStream in Qt 5.
Pick-to: 6.2
Fixes: QTBUG-97995
Change-Id: Id3c6e13fc2375685643caee5f8e3009c00918ccb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Since e05e3c7762, the advance test in
tst_QFontDatabase::condensedFontMatching() passes with the bundled
freetype engine, so the XFAIL causes a failure when running with this
configuration.
Pick-to: 6.2
Change-Id: Ie6fbccfa0d9c79654563e9e3f19694f252e32fc6
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Don't rely on transitive include from qobject.h, which will go away.
Change-Id: I99dd97ff4fb1d0632d040daab0bffa2d7b85d3ae
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Arrays of textures have always been supported, but we will encounter
cases when we need to work with texture array objects as well.
Note that currently it is not possible to expose only a slice of the
array to the shader, because there is no dedicated API in the SRB,
and thus the same SRV/UAV (or equivalent) is used always, capturing
all elements in the array. Therefore in the shader the last component
of P in texture() is in range 0..array_size-1.
Change-Id: I5a032ed016aeefbbcd743d5bfb9fbc49ba00a1fa
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Unify the logic in QTextEngine
Ensure tightBoundingRect, and the FreeType boundingRect, calculates from
the shaped x offset when calculating the max x coordinate for a glyph.
Fixes: QTBUG-7768
Task-number: QTBUG-70184
Task-number: QTBUG-85936
Task-number: QTBUG-94023
Change-Id: I6daafb25c79158dc7e777529abb5e8d3a284dac0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QWidget will call close() in its destructor, which we might end up
in if a user deletes the widget in the closeEvent.
Pick-to: 6.2
Change-Id: I39684aec0ca130033dad60f2bbf823364a5edcec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In a512e210ac5b032c5fc2edf1ddf72e5a414485fda512e21 quitOnLastWindowClosed
was changed to be implemented in terms of quitLockEnabled, but without
any documentation to that end.
Although the two features are similar (automatic quit under certain
conditions), and interact, it doesn't make sense to overlap them until
we actually expose them as a single property (automaticQuit e.g.)
The logic for determining whether we can can quit automatically has
been refactored to take both properties into account, on both a Core
and Gui level. The call sites still need to check the individual
properties to determine whether to activate automatic quit for
that particular code path.
Change-Id: I38c3e8cb30db373ea73dd45f150e5048c0db2f4d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When the cursor is positioned between to script items that have different
writing directions, prioritise the script item that has the same direction
as the paragraph (i.e. the QTextEngine) when deciding where and how to
display the cursor. If visual cursor movement is enabled, the behavior is
unchanged.
As a drive-by, clean up coding style and avoid shadowing of function-
local variables.
Task-number: QTBUG-88529
Pick-to: 6.2
Change-Id: I15227b10b1469d9caf1235b00e4d6f9f64a8b510
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In a text line that has a change of direction at either end of the text,
the cursor needs to be positioned where the next character is inserted,
or where backspace deletes the previous character. In bidi text, this is
ambiguous as illustrated by this example:
abcشزذ
Depending on whether this string was typed in a left-to-right document
or in a right-to-left document, it could be first latin, then arabic; or
it could be first arabic, then latin.
If a general left-to-right context, cursor position 0 should be in front
of the 'a', and cursor position 6 should be at the end of the arabic
text, in the visual middle of the line. Cursor position 3 can be either
after the 'c' if the next character typed would be latin, or at the
visual end of the line if the next character will be arabic.
Qt calculated the cursor position past the right end of the text as 3
(which is not wrong, but 3 has two visual positions), and placed the
cursor at the visual end of the line (favoring the right-to-left
alternative). Backspace would then delete the 'c', writing a new
latin character would insert a 'd' next to the 'c', writing a new arabic
character would insert it also in the middle - none of these operations
happen at the visual end of the line, where the cursor was blinking.
To fix this, we take into account the general layout of the text, which
is typically based on the document, or the user's locale setting and UI
translation, and calculate the cursor position accordingly: if we are
past the visual end of the document on either side, then the cursor
position is either 0 or the last character of the text, depending on the
direction of the QTextEngine used. This way, the cursor ends up in the
middle of the document when we click beyond the end of the line, which
is where characters are removed and inserted. Typing a 'd' at this point
will make the cursor jump to the end, where the d is added.
There are still corner cases: clicking on the right-most arabic character
calculates the cursor position as 3, which is then ambiguous, as it can
be either at the visual end of the string, or next to the 'c'. َQt makes
the inconsistent choice to place the cursor at the visual end, showing
the left-to-right indicator, but pressing a 'd' adds the 'd' after the
'c' in the middle of the text.
Fixes: QTBUG-88529
Pick-to: 6.2
Change-Id: Idccd4c4deead2bce0e858189f9aef414857eb8af
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If an entity occurs directly in markdown, we parse and insert it
directly; but if it occurs in an HTML block, it has to be added to the
HTML accumulator string for deferred parsing when the HTML block ends.
Pick-to: 6.2
Fixes: QTBUG-91222
Fixes: QTBUG-94245
Change-Id: I0cf586d68d6751892ca035a98f77cd67950d3bc4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
- Under a list item, we've been indenting code blocks:
```
int main() ...
```
- But it's also ok *not* to indent (and github handles that better):
```
int main() ...
```
- There was a bug that when the code is not indented, the fence would be
indented anyway:
```
int main() ...
```
and that was not OK, neither for md4c nor for github.
Now with this change, either way is rewritable: you can read markdown
into QTextDocument, make small edits and write it back out again, with
the indentation being preserved (the code block is either part of the
list item, thus indented, or else it's outside the list completely).
Pick-to: 6.2
Task-number: QTBUG-92445
Change-Id: I5f51899e28ba9f09b88a71e640d9283416cce171
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
[ChangeLog][QtGui][CSS] The background-color style can now be applied to
<hr/> to set the rule color.
Task-number: QTBUG-74342
Change-Id: Ib960ce4d38caa225f258b6d228fb794cef43e1b7
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
When parsing CSS, a border-color value is parsed as four brushes, as css
allows assigning up to four values, one for each side.
When applying the CSS to the HTML, we accessed it as a color value,
which overwrote the parsed value with a QColor. So while we had a valid
parsed value (and didn't re-parse), the code accessing that value still
expected it to be a list, and thus failed to retrieve the data.
There are several ways to fix that, but the cleanest way without
introducing any performance penalty from repeatedly parsing (and in fact
removing a parse of the string into a color) is to enable colorValue to
interpret an already parsed value that is a list without overwriting the
parsed value again. To avoid similar issues in the future, add assert
that the parsed value has the right type in brushValues.
As a drive-by, speed things up further by making use of qMetaTypeId
being constexpr, which allows for it to be used in a switch statement.
Add a test case.
Fixes: QTBUG-96603
Pick-to: 6.2 5.15
Change-Id: Icdbff874daedc91bff497cd0cd1d99e4c713217c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
They return a pointer to the actual header, skipping the magic string.
This is done in preparation for the header located in an ELF note, which
won't have the magic.
Change-Id: I3eb1bd30e0124f89a052fffd16a8229bec2ad588
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
- Those files were moved as part of Qt3D as its the sole
user of these
- Also removed associated unit tests
Pick-to: 6.2 5.15
Change-Id: I302bc219218a58071c86d2447cb4449601fca32c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mike Krus <mike.krus@kdab.com>
We can only start timers in threads started via QThread, and even then
we cannot assume that the thread runs an event loop. So only start the
timer when we are in the main thread.
Add a test that verifies that we don't get the warning message.
Pick-to: 6.2
Change-Id: I40d7d9ff115720f9ecd3eedaebbade2643daf843
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Unlike the other conversion functions, convertWithPalette() did not
call copyMetadata().
Fixes: QTBUG-96926
Pick-to: 6.2 5.15
Change-Id: I2b171cec16bc5a90d33e80d6fe178c650ed3fe36
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
After the recent refactoring in 28b14b966f
this test should run stable on all platforms. However, the way the test
was written made it quite flaky. Simplify it to verify that closing one
window doesn't prevent a second timer to fire (which it would if closing
the first window already quit the application).
Change-Id: I0306792cd7573ebd3418d1aabffe2b78700ec2d9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Verifies that we get the messages we want, and makes it easier to see
relevant debug output.
Pick-to: 6.2
Change-Id: Ide92959b120f325badbf200236cdc85f72226e1e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
- process environment/DNS are OFF for INTEGRITY
Task-number: QTBUG-96176
Pick-to: 6.2
Change-Id: I189a97f88c96a428586c31a66b8d250e04482900
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QVLA itself is non-relocatable due to self references. (ptr pointing
to array[Prealloc] as long as capacity < Prealloc)
Seems we shot ourselves in the foot in multiple places with this.
Pick-to: 6.2 6.2.0
Fixes: QTBUG-96619
Change-Id: I57a2ce539b671326cd352dbe57a1f3d4c46a6456
Reviewed-by: Tobias Koenig <tobias.koenig@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The QDoubleValidator::setRange() used to have 3 parameters, with
the third one (the number of decimals) having a default value of 0.
Such default value does not make much sense for a *double* validator.
Also, since a default value was used, omitting the decimals was
silently overwriting the previous decimals value, discarding the
value that could be previously explicitly specified by user.
[ChangeLog][QtCore][QDoubleValidator][Important Behavior Changes] The
QDoubleValidator::setRange() method now has two overloads.
The first overload takes 3 parameters, but does not support a
default value for decimals.
The second overload takes only two parameters, not changing the
number of decimals at all.
Hence, the number of decimals will only be changed if the user
explicitly specifies it.
To maintain the old behavior of setRange(), pass 0 as the 3rd
argument explicitly.
Note that it is a source-incompatible change. But it should be fine,
because using QDoubleValidator with 0 digits after decimal point does
not make much sense and so, hopefully, is not that common.
At the same time, change the default-constructed QDoubleValidator
to use -1 for decimals, which allows arbitrarily many digits in
the fractional part. The value was previously 1000, which allowed
more than anyone would reasonably use, so this should make no
practical difference.
Some more unit tests to cover the behavior of the setRange()
overloads are also added.
As a dirve-by: remove unnecessary QValidator::State to int conversions
in the unit tests. QCOMPARE is capable of comparing these enums and
provides a better output in case of failure for enums.
Task-number: QTBUG-90719
Change-Id: I523d6086231912e4c07555a89cacd45854136978
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It is no longer handled separately from Android.
This effectively reverts commit 6d50f746fe
Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
...when starting a render/compute pass.
This matches most other backends in fact, the Vulkan backend has
just certain historical differences, and is complicated due to the
fact that it has the option of using secondary command buffers for
passes that specify ExternalContents (to support the case of wanting
to issue direct Vulkan commands in a code block surrounded by calls
to beginExternal and endExternal).
Not resetting state such as the currently bound index buffer when
starting a pass quickly blows up when two consecutive render passes
use different settings, one targeting the primary while the other
the secondary command buffer. Instead of further complicating the
logic, just reset the relevant state in every begin(Compute)Pass.
Comes with an autotest that is crafted so that it manages to
downright crash when run with Vulkan without the fix to the backend.
Fixes: QTBUG-89765
Pick-to: 6.2
Change-Id: I8dc47bd179c17d45a0556ec31200dc90c4b67ca5
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The provided implementation tries to fix positions for the group
separator.
In case of scientific notation it can also converts the value to
normalized form.
It uses QLocale::FloatingPointShortest internally to convert the
double value back to string, so the number of decimals may change
after calling this method.
Change-Id: I963bc5f97b653e2bb912f4b95b09a4d1ee201e7f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Follow what has been done for QRhiShaderResourceBindings. Have a way
to retrieve an opaque blob (that just happens to be a list of integers)
so that a simple == comparison can be used to determine compatibility
even when the objects from which the blob was retrieved are no longer
alive.
The contract is the following:
bool a = rp1->isCompatible(rp2);
bool b = rp1->serializedFormat() == rp2->serializedFormat();
assert(a == b);
Pick-to: 6.2
Change-Id: I45e7d05eeb6dfa2b2de474da0a0644912aaf174a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
a332f3fabc disabled resolving all fonts
on the system for every font lookup, which was a significant startup
time improvement. But it also caused a regression: When a font has
an alias which shares the name of a proper font, then this would
not be resolved correctly.
This is fairly typical on Windows/GDI due to backwards-compatibility.
Instead of being collected under a shared typographical family, fonts
are disambiguated by adding the style name to the family name. The
proper typographical name is still available, but this is not
enumerated by the system.
So "Segoe UI" for instance, will be available as "Segoe UI",
"Segoe UI Light", "Segoe UI Bold" etc.
When we populate family aliases, we register that "Segoe UI Light"
is actually "Segoe UI" with Light weight, and prior to
a332f3fabc this would be done implicitly.
But after the optimization, we would only populate family aliases once
we stumbled over a font request for a non-existent font. For "Segoe UI",
we would simply return the regular weight font as the best imperfect
match.
The fix is to populate font family aliases not only when the family is
non-existent, but when the match is imperfect, e.g. if we are asking
for a Light weight font and only finding a regular one. User code can
still avoid this somewhat expensive operation by using the full
family names on Windows.
This also requires a fix to a test. When removeApplicationFont() is
called, we invalidate the font database, so it will be reset to a state
that does not contain the family aliases. Therefore we cannot guarantee
that it is identical to what it was before the test started, since this
depends on what has happened previously in the application.
[ChangeLog][QtGui][Text] Fixed an issue where some font styles and weights
would not be selectable. This was especially noticeable on Windows.
Pick-to: 5.15 6.1 6.2
Fixes: QTBUG-94835
Change-Id: I892855edd1c8e3d3734aace396f6000d897d2ec4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Export configuration() and setConfiguration() from the offscreen
platform plugin using QPlatformNativeInterface. tst_qighdpi can
then resolve and make use of them since it always uses the offscreen
platform plugin.
Add screenDpiChange() auto test.
Change-Id: I459b4df5d94ec4991234a346e3a94618cb3485e9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Noticed the missing tests while implementing fixup() for
QDoubleValidator.
Change-Id: Ic0e053a6385e311e4a491c8bff8ec7fbb83c3944
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Be idiomatic and return the output iterator one past the last element.
Otherwise passing in a plain pointer (as exercised by the autotest now)
fails to function because we write over the same 4 elements again and
again for each binding.
Pick-to: 6.2
Change-Id: If74463fa5140ffa2b1d5be97b71868848ad46614
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
...by the Qt Quick renderer, for example.
A typical Qt Quick material binding set serializes to 8 uints. This
would not demand a container like QVector. However, being implicitly
shared is essential here due to the intended usage (query the
serialized blob, put it into a cache key, hash it, compare it, all
without any copying and new allocs; we can afford an extra alloc
upon each srb construction, but don't want more afterwards in the
rendering engines)
Also make it clear in the pipeline docs that the optimization Qt Quick
is (soon going to be) doing is legal. (the srb ref in the pipeline can
be dead and dangling as long as every call to setShaderResources()
specifies a layout-compatible alternative)
Pick-to: 6.2
Change-Id: I97efbea1fa3516b10c9832adbab0a21b7bc0845d
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Verify that closing a QWindow using either the close()
API or a close event works as expected, and that the window
can be re-created. Also test QWindows with child windows.
Task-number: QTBUG-46701
Change-Id: I4c12452ff58e1233536c2d6932e72cf924d8ed74
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We can't really compare two NaN's. Should use qIsNaN() for that.
Pick-to: 6.2
Change-Id: Ia514cabe65cfcdeafb39cab91ecdb66f8fae725c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When using NoFontMerging, no fallbacks should be resolved. If the
font does not support a specific character in the text, we should
display a box instead of merging it with another font.
But in practice, Qt would still apply the fallback mechanism for
one specific case: If the font itself does not support the script
of the text, we would get no match and do a search for a fallback
instead. Since NoFontMerging is set, we would then force this
as preresolved for *all* scripts in the QFont's private data
(logically, the match should only have a single response for
NoFontMerging).
The end result was that if you set the font family before updating
the text, you would get broken rendering. This can happen e.g. in
Qt Quick, where you could update the font family of a text label
while it contains characters which are not supported by the new
font. Qt would then pick a fallback instead. When you subsequently
update the text, the fallback would already be preresolved for
whatever script this is. If it does not support the updated text,
we would then see boxes, even if the requested font actually would
have supported it.
The fix is simply to do an additional pass if NoFontMerging is set
and we were not able to match with the specified script. Since
the same family might be available in different foundries, with
different writing system support, we still want to do a pass first
to see if we can match the exact script of the text.
Note that QRawFont::fromFont() exploited the bug by using
NoFontMerging for getting the fallback font for a specific
writing system. To keep this working without having to rewrite
fromFont() and risk introducing regressions, we add an argument
to make the findFont() function behave as before. It isn't
super-pretty, but since it is private API it is hopefully fine.
[ChangeLog][QtGui][Text] Fixed an issue with NoFontMerging and
changing font families dynamically, where boxes would be seen in
place of the correct text.
Pick-to: 5.15 6.1 6.2
Done-with: Andy Shaw
Fixes: QTBUG-81770
Change-Id: Ide9a36d7528a1040172c5864fa99e7a82eac4e83
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Remove SRCDIR defines from tests that don't use them. There is a
standard define called QT_TESTCASE_SOURCEDIR that is available to all
tests and serves the same purpose.
Pick-to: 6.2
Change-Id: I2aa237739c011495e31641cca525dc0eeef3c870
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Replace custom SRCDIR define with QT_TESTCASE_SOURCEDIR. The latter is
automatically available to all tests to use and serves the same purpose
but is not terminated by a slash.
Change-Id: I62896d0fd84ac63ac1b74a459ec1646c6bde0a46
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Previous fix hit too widely so some valid horizontal and vertical
lines were affected; the root problem being that such lines have an
empty control point rect (width or height is 0). Fix by caculating in
the pen width.
Pick-to: 6.2 6.1 5.15
Change-Id: I7a436e873f6d485028f6759d0e2c6456f07eebdc
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The QtTest best practices documentations recommends using output
mechanisms such as qDebug() and qWarning() for diagnostic messages,
and this is also what most of our own tests do.
The QWARN() macro and corresponding internal QTest::qWarn() function
was added when QtTest was first implemented, but was likely meant as
an internal implementation detail, like its cousin QTestLog::info(),
which does not have any corresponding macro.
This theory is backed by our own QtTest self-test (tst_silent)
describing the output from QWARN() as "an internal testlib warning".
The only difference between QWARN() and qWarning(), besides the much
richer feature set of the latter, is that qWarning() will not pass
on file and line number information in release mode, but QWARN() will.
This is an acceptable loss of functionality, considering that the user
can override this behavior by defining QT_MESSAGELOGCONTEXT.
[ChangeLog][QtTest] QWARN() has been deprecated in favor of qWarning()
Pick-to: 6.2
Change-Id: I5a2431ce48c47392244560dd520953b9fc735c85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
One is a bad application or library in this case, but nonetheless
we should handle this more gracefully then just crashing due to
the QRhi already having been destroyed. Mainly because in Qt 5 one
could get away with the same: releasing OpenGL objects underneath,
for example, a QSGPlainTexture with no (or wrong) GL context did
not generate any user visible fatal errors. So we should not crash
in Qt 6 either with these code bases.
In debug builds or when QT_RHI_LEAK_CHECK is set, one will get the
unreleased resources warning printed in Qt 6, which is a step
forward compared to Qt 5. So there is still some indication that
something is badly designed, even if the application survives.
Task-number: QTBUG-95394
Pick-to: 6.2
Change-Id: I944f4f425ff126e7363a82aff926b280ccf1dfc3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
layoutAboutToBeChanged must be called before
persistentIndexList as the user might create persistent indexes
as a response to the signal
Fixes: QTBUG-93466
Pick-to: 6.2 5.15
Change-Id: I73c24501f536ef9b6092c3374821497f0a8f0de4
Reviewed-by: David Faure <david.faure@kdab.com>
When saving to a QIODevice, QImage and QImageWriter will automatically
deduct the file format from the filename if it determines that the
device is a QFile. That did not work for a QSaveFile device. Fix by
using the common ancestor, QFileDevice, in the implementation.
Fixes: QTBUG-89022
Pick-to: 6.2
Change-Id: Ie01d80df4f29ca0d4ff30bf7e1b77605293c070e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
... instead of raw pointers or QSharedPointer.
Raw pointers are, of course, a no-no in modern code. In particular,
when the result is then held in shared_ptr or QSharedPointer,
make_shared or QSharedPointer::create() should be used to reduce
number of memory allocations.
Since this is private API, we're free to use std::shared_ptr, which
does only half the atomic operations on copies, compared to
QSharedPointer, so is more efficient.
For either make_shared or QSharedPointer::create(), we need to work
around the private ctor, which we do by inheriting a member-function
local class from QColorTrcLut and make_shared'ing that. As a
member-function-local class, it has access to the otherwise private
parts of QColorTrcLut, including its default constructor. As a public
subclass, shared_ptr has no problem performing the derived-to-base
pointer adjustment in the return statement. This way, we can use
make_shared even though our target's class' ctor is private.
Change-Id: Icb11249b54cd5e544e692f6a0bf1f9dda1710454
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
... by making the test class a friend of the CUT, as we do elsewhere
for the same reason.
This allows to remove the duplicated enum and struct in favor of using
The Real Thing™, which means the test can no longer go out of sync
with the CUT anymore.
Change-Id: I87dc8bb4a5476ae4fc99e006c4690e96d2f530d2
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
