... when we are not using the FFD_USE_FORK flag. We use the FFD_USE_FORK
flag when we have user code to run in setupChildProcess(). This code is
enabled for all Unix, but forkfd() honors this flag only on Linux >=
5.4.
See the commit adding the flag for more information on what the flag
does and see the comment in this commit on why it's safe to use it.
Fixes: QTBUG-17331
Change-Id: I1bee3bc466a04f19bd6efffd15f448cb23ce1e91
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This flag asks forkfd() to use vfork semantics wherever available. That
is, suspend the calling process execution until the child either does an
execve(2) or _exit(2). The advantage of that is that it puts lower
pressure on the OS VMM system, as the number of pages that need to be
copy-on-write duplicated is much smaller (still not zero, as at least
the stack in the child will be written to).
However, the only implementation that supports using this flag for now
is Linux's pidfd. It would be possible to add to FreeBSD, but pdfork(2)
does not have a flag for this behavior -- if it gets one, we can add
support for it later. Everywhere else, we need to force the child to not
exit until we store the child process's PID in the ProcessInfo structure
we allocated, which means the parent process must run before we even
return from forkfd().
Change-Id: I1bee3bc466a04f19bd6efffd15f447f28c201aa9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If we detected that the OS supports a version of system forkfd (Linux
pidfd, FreeBSD procdesc), the forkfd_wait() function was using only the
system waiting implementation, which of course can't work for file
descriptors created with FFD_USE_FORK. So just detect EBADF and attempt
again.
If the file descriptor is neither one of our pipes nor a system forkfd,
bad things will happen...
Fixes: QTBUG-82351
Change-Id: I4e559af2a9a1455ab770fffd15f59fb3160b22eb
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
"wait4" because it looks like the wait4() BSD function, which has the
signature:
pid_t wait4(pid_t pid, int *wstatus, int options,
struct rusage *rusage);
And because ours also has 4 parameters.
Having options is important anyway. I might want to add some more later,
but we can't really support them with the fall back implementation (in
fact, we don't honor WNOHANG in the fall back implementation either).
Change-Id: I4e559af2a9a1455ab770fffd15f5858bb357e15b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Currently depending if user uses QApplication
or QGuiApplication we end up in different behavior
when running post routines. For example QApplication
destructor calls post routines before stopping event dispatcher,
In case of QGuiApplication post routines are called
from QCoreApplication destructor, so no more event dispatcher.
This behavior is not consistent and creates troubles
when releasing resources of web engine.
Attached test will hang on windows with QGuiApplication,
however works fine with QApplication.
Task-number: QTBUG-79864
Change-Id: Ice05e66a467feaf3ad6addfbc14973649da8065e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
These functions and macros were never documented.
Let's warn about using them for now, with the option of
removing / renaming them in Qt 6.
Change-Id: Ia595aa35b73e54534e535d2946581651af8023f2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use range-based for and fix deprecation warnings.
Change-Id: I54152b2598e9e4a7a3cc9db9b7072bbabcef7fcf
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Don't introduce another overload with two parameters. Users
want a simple signal to connect to, not another overload. Deprecate
the currentIndexChanged(QString) overload, usage of that can/should
get replaced by currentTextChanged().
This partially reverts commit 11dc7b35c8.
Change-Id: I5e7d16413f3d62b1a5a7a197f510af2c45cdfa55
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
When creating a new QColorSpacePrivate it must be reffed otherwise in
the destructor the deref() will bring the count to -1 which is true
and will not delete the d_ptr.
Change-Id: Id569bae22134b56bf6ad37158d7079b495599fd7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
(cherry picked from commit 20eabb72de)
QtQuick3D probes for the supported OpenGL level by testing
multiple OpenGL versions in descending order. Context creation
must fail for versions not supported by WebGL. It does not
appear that Emscripten does this for the 3.x minor versions,
at least.
Add version check which allows OpenGL (ES) 3.0 and 2.0.
Change-Id: Ide8745dd79e69af86812a8d6f5d6cc16ecdd099a
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This reverts commit bcdf49bcc6.
This was a 5.14-only commit which accidentally found its
way to 5.15.
Change-Id: Iaef6f05fce20ab61d3afb8cb3c359a037e4c0b28
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Remove some unneeded empty lines, and fix indentation.
Change-Id: Ie35e95f35f9625cc75070074be96bdeb62d5fd4c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There are some plugins in qtlocation, qtdeclarative whose names are not
suffixed with 'Plugin', so the current logic fails to load the
corresponding QtModule_XXX.cmake file.
Work around this by just searching for
Qt5$${CMAKE_MODULE_NAME}}_*.cmake.
Users can define QT5_STRICT_PLUGIN_GLOB
or Qt5$${CMAKE_MODULE_NAME}_STRICT_PLUGIN_GLOB
to change back to the old behavior.
[ChangeLog][cmake] Fixed an issue where some Qt location and
declarative plugins whose name did not end with "Plugin"
where not imported by the corresponding Qt component package.
You can force the old behavior by setting QT5_STRICT_PLUGIN_GLOB or
Qt5ModuleName_STRICT_PLUGIN_GLOB before the find_package(Qt5 ...)
call.
Fixes: QTBUG-58812
Change-Id: Ic8adf9562841ed49eabc4f7fb2b5ae257ca606cd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This allows to pass and receive possible drop actions from other
processes, including GTK applications.
Fixes: QTBUG-75744
Change-Id: I944edc6fa00f8801a25912e70eb104a647a9fc0e
Reviewed-by: JiDe Zhang <zccrs@live.com>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Given:
struct Light { vec4 foo; };
layout(std140, binding = 2) uniform material {
Light light;
int lightCount;
};
the previous code would keep "light" appended for the prefix and look for
`light.lightCount`.
Change-Id: Ia8deacd0cb4833f45151e922fa7b5970169332eb
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
[ChangeLog][WebAssembly] Updated emscripten to version 1.39.8
Change-Id: I8d19f851eb0c0dd912792cee0db69e61cf4fd5f6
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Don't try to update the scrollarea geometry while resizing a row or
column since this may lead in flickering and artifacts, esp when the
scroll mode is scrollPerItems. Instead do the calculation only when the
resize is finished.
Fixes: QTBUG-72870
Fixes: QTBUG-82595
Change-Id: Id6903c00485b3be6ed54bd5f9bcafdda6da21598
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Remove references to the deprecated QGLWidget and replace it with
QOpenGLWidget.
Change-Id: Ia31df42ab61c25e9ce46f4491267d2c64910f55c
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
QDateTimeEdit very aggressively prevents user input that would result in
values that are outside the dateTimeRange. While keyboardTracking is on
this makes sense, as otherwise the dateTimeChanged signal would be
emitted after each section, with a value that is outside the range.
However, this prevented users from entering a date that is allowed, but
where sections of the date are above or below the respective section in
the maximum or minimum value.
If keyboardTracking is off, QDateTimeEdit only emits the dateTimeChanged
signal at the end of editing, when focus is lost or the return key is
pressed, and then it enforces that the value is within the range anyway.
This change makes the parser ignore the range during editing if
keyboardTracking is off, thus allowing the user to enter a date where
temporary values are outside the range.
The test makes sure that we don't get signals emitted with out-of-range
values, testing both with and without keyboard tracking.
Change-Id: I00fb9f1b328a3477163f890c4618b40878657816
Fixes: QTBUG-65
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The rewrite using CBOR internals replaced one of the two naked pointers
that were members of QJsonArray and QJsonObject with a
QExplicitlySharedDataPointer. The problem is that its operator= will
read the current value to decrement the refcount and possibly delete the
pointed object.
But QJson{Array,Object}::initialize() are called from inlined code,
without initialization. So we can't call operator=. We need to memcpy to
write a nullptr.
This is not unit-testable because it requires compiling against 5.14 or
earlier, then running against 5.15.
Fixes: QTBUG-82700
Change-Id: Iaa63461109844e978376fffd15f98c62656d197c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
the non-const QJsonArray::operator[] requires a valid index and all the
const operator[] say that it returns Undefined if the key or index
doesn't exist. This is the exception.
Task-number: QTBUG-39864
Change-Id: Iaa63461109844e978376fffd15f9716f0cc66cca
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We don't support 1.0 any more, and 1.1.0 has reached EOL.
Bump to 1.1.1 so we can freely use its APIs.
[ChangeLog][QtNetwork][SSL] The minimum required version
of OpenSSL is now 1.1.1.
Change-Id: I5cfb6672fadfa48aedaefbcd6a954aa9eb85bfa5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Constantly re-reading the timezone information only to be told the exact
same thing is wildly expensive, which can hurt in operations that cause
a lot of QTimeZone creation, for example, V4's DateObject - which
creates them a lot (in DaylightSavingTA).
This performance problem was identified when I noticed that a
QDateTime binding updated once per frame was causing >100% CPU usage
(on a desktop!) thanks to a QtQuickControls 1 Calendar (which has a
number of bindings to the date's properties like getMonth() and so
on).
The newly added tst_QTimeZone::systemTimeZone benchmark gets a ~90%
decrease in instruction count:
--- before
+++ after
PASS : tst_QTimeZone::systemTimeZone()
RESULT : tst_QTimeZone::systemTimeZone():
- 0.024 msecs per iteration (total: 51, iterations: 2048)
+ 0.0036 msecs per iteration (total: 59, iterations: 16384)
Also impacted (over in QDateTime) is
tst_QDateTime::setMSecsSinceEpochTz(). The results here are - on the
surface - less impressive (~0.17% drop), however, it isn't even
creating QTimeZone on a hot path to begin with, so a large drop would
have been a surprise.
Added several further benchmarks to cover non-system zones and
traverse transitions.
Done-With: Edward Welbourne <edward.welbourne@qt.io>
Task-number: QTBUG-75585
Change-Id: I044a84fc2d3a2dc965f63cd3a3299fc509750bf7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Very similar to source-over, but have traditionally been inlined.
Change-Id: I211f0b1c91c1a00c4769fbbfe2e3d0c7b22d7048
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
...between setGraphicsPipeline() calls with different
QRhiGraphicsPipeline instances within the same pass.
Also adds similar logic for the GL_ARRAY_BUFFER (vertex buffers)
as that is a hotspot as well.
This is not intended to be a 100% avoiding any redundant call solution,
but rather to take care of the most common hotspots, so that bad OpenGL
implementations with a larger API call overhead will not cause us to
regress compared to the direct OpenGL rendering path in Quick and
Quick3D.
What we have here reduces the number of GL calls in the view3d example
by ~200 within one frame, which is a pretty good start.
Task-number: QTBUG-78603
Change-Id: I6aeab9c1c43b148ea6ef05d0284990a996c7ba28
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Keypad navigation within a group should work for auto-exclusive buttons,
or for checkable buttons that are in a button group. Since the code
already tests whether the button should be treated like an exclusive
(which implies checkable) button, use the result of that test when
finding the candidate button to move focus to, and not only when
actually changing the checked button and the focus.
Change-Id: I4dc41a90d51a8304483046252ceff0ebfe2a2e52
Fixes: QTBUG-27151
Done-with: david.faure@kdab.com
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Test fails on MinGW 8.1 x86, but not on MinGW 8.1 x86_64.
Task-number: QTQAINFRA-3304
Task-number: QTBUG-69947
Change-Id: Ie9a35bd6d5a8481028cd0ea426d1cf00bd7cf093
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
It was introduced in Qt 4.4 (e150f6a6e619) to work around slow resizes
on Windows and X11 due to excessive painting, but has since been removed
when old dead code never ported to QPA was removed in a2337f79ff.
Change-Id: Ic14e714a02edb4194a445a6bb0759b601799fdc6
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
