| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Change-Id: Iba540adaeffb0098fc4e1923050eb611bf47287b
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch adds support to switch on anisotropic filtering on
QSGTexture and to QSGDefaultImageNode.
Not adding this support to QSGImageNode since it became public
in 5.8, and it does not allow additional virtual methods anymore.
Change-Id: Ibf1744845df2297f9129b1b5ce6a69d0a3b31c7c
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Gunnar Sletta <gunnar@crimson.no>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generic backend uses the triangulator from QtGui, but is in
fact OpenGL-only for now due to materials.
The NVPR backend uses GL_NV_path_rendering on NVIDIA hardware with
OpenGL 4.3+ or OpenGL ES 3.1+.
The software backend simply uses QPainter.
With the generic backend each PathItem is backed by a non-visual root node
and 0, 1 or 2 child geometry nodes, depending on the presence of visible
stroking and filling. The potentially expensive triangulation happens on
updatePolish(), on the gui thread. This is proven to provide much smoother
results when compared to doing the geometry generation on the render thread
in updatePaintNode(), in particular on power-limited embedded devices.
The NVPR backend uses a QSGRenderNode in DepthAware mode so that the batch
renderer can continue to rely on the depth buffer and use opaque batches.
Due to not relying on slow CPU-side triangulation, this backend uses 5-10
times less CPU, even when properties of the path or its elements are
animated.
The path itself is specified with the PathView's Path, PathLine, PathArc,
PathQuad, etc. types. This allows for consistency with PathView and the
2D Canvas and avoids a naming mess in the API. However, there won't be a
100% symmetry: backends like NVPR will not rely on QPainterPath but process
the path elements on their own (as QPainterPath is essentially useless with
these APIs), which can lead to differences in the supported path elements.
The supported common set is currently Move, Line, Quad, Cubic, Arc.
The patch introduces PathMove, which is essentially PathLine but maps to
moveTo instead of lineTo. More types may get added later (e.g. NVPR can do
a wide variety of optimized rounded rects, but this requires directly
specifying a GL_ROUNDED_RECTx_NV command, thus neededing a dedicated Path
type on our side too)
For filling with gradients only linear gradients are supported at the
moment.
In addition to the declarative API, a more lightweight, QObject-less
JS-callable API should be considered as well for the future.
Change-Id: I335ad64b425ee279505d60e3e57ac6841e1cbd24
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Instead use QT_CONFIG(foo). This change actually detected a few
mis-spelled macros and invalid usages.
Change-Id: I06ac327098dd1a458e6bc379d637b8e2dac52f85
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
| |
Without theses additional #ifdefs building with clang fails.
Change-Id: Ib6993b6d14bf73b606e1bcb991f7436a9c4c9638
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
| |
Change-Id: I4b7f9ef379f2641da9c06572daa5ba41b03dd994
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
|
|
|
|
|
| |
Change-Id: Ia4243de07ec75030bb98f4f6d95f70d88e29fdba
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
|
|\
| |
| |
| | |
Change-Id: If33197b616de3476811f0161d4ecd8e7d004756c
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change also fixes the build of two benchmarks, tst_affectors
and tst_emission.
Conflicts:
src/plugins/qmltooling/qmldbg_native/qmldbg_native.pro
src/qml/qml/ftw/qhashfield_p.h
tests/benchmarks/particles/affectors/tst_affectors.cpp
tests/benchmarks/particles/emission/tst_emission.cpp
tests/benchmarks/qml/pointers/pointers.pro
tests/benchmarks/qml/pointers/tst_pointers.cpp
tests/benchmarks/qml/qmltime/qmltime.pro
tests/benchmarks/qml/qquickwindow/qquickwindow.pro
Change-Id: I595309d1e183c18371cb9b07af6e4681059de3b2
|
| | |
| | |
| | |
| | |
| | |
| | | |
Change-Id: Ib1c2695f86837b02ba4aaf49184421cd464f7c20
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently the Qt Quick module depends on either the OpenGL or OpenGLES
headers being available at build time. Since we are adding support for
adaptations that do not depend on OpenGL, it should be possible to build
Qt Quick in environments that do not have OpenGL development headers.
This does present many challenges though because in some cases GL types,
and classes that require OpenGL are part of the public APIs. However
since these classes were never available when QT_NO_OPENGL was defined,
it should be possible to redefine the function signatures under this
scenario, since it's not possible to break binary compatibility if there
never were any binaries to break compatibility with.
One of the bigger changes that was necessary to facilitate this change
is creating interfaces out of QSGContext and QSGRenderContext. Here the
default behavior was usage of OpenGL directly, even though subclasses
could override all OpenGL usage. Making them interfaces should bring
QSGContext and QSGRenderContext more in line with the other classes
present in the adaptation layer.
Change-Id: Iaa54dc0f6cfd18d2da1d059548abf509bd71f200
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
|
|/
|
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9
Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3 & LICENSE.GPLv2
- Removed LICENSE.GPL
Change-Id: I84a565e2e0caa3b76bf291a7d188a57a4b00e1b0
Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
|
|
|
|
|
| |
Change-Id: I9a55bcbf9e94084c0cadac561e4707d47f5f8744
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
15999f14f146b5c04fb40b31b69ceeeece273430 changed QSGPlainTexture so it
allows mipmap filtering by default. This requires a call to
glGenerateMipmap() for textures to be valid, if mipmap filtering is
used. Our texture materials follow the GL default which is to use the
somewhat useless GL_NEAREST_MIPMAP_NEAREST. As a result we've had a
number of bugs where textures are used and the call to
glGenerateMipmap() is omitted. This happens for instance when using
QQuickTexture::createTextureFromId().
Generating mipmaps by default is also a serious performance regression.
To remedy this and minimize the impact on existing code, we disable
mipmapping by default.
[ChangeLog][QtQuick][SceneGraph] QSGTextureMaterial and
QSGOpaqueTextureMaterial uses QSGTexture::None as default mipmap mode.
Task-number: QTBUG-38321
Change-Id: Ia9d09fbcf710efb4575938053d0a2046f604a197
Reviewed-by: Caroline Chao <caroline.chao@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
The counterpart to I716fdebb. Implements the dynamic path
in scenegraph.
Task-number: QTBUG-36483
Change-Id: I2dc613ba84560b7b8e36d3cd1da61c050ab08db0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default implementation of QSGShaderMaterial::vertexShader() and
fragmentShader() now loads the GLSL source from a list of source files
that can be specified via the setShaderSourceFile() or
setShaderSourceFiles() functions.
Multiple shader source files for each shader stage are supported. Each
source file will be read in the order specified and concatenated
together before being compiled.
The other places where Qt Quick 2 loads shader source code have
been adapted to use the new QSGShaderSourceBuilder, which is also
used internally by QSGMaterial.
This puts Qt Quick 2 into a better state ready to support OpenGL
core profile and to load different shaders based upon OpenGL version,
profile, GPU vendor, platform, etc.
Change-Id: I1a66213c2ce788413168eb48c7bc5317e61988a2
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
| |
Change-Id: I3750c47640bf21c3567c5fa1c4667e3e2552942e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found by ICC 14. This warning is not made an error because ICC is too
chatty when it comes to detecting unused functions. In this case,
however, it is right.
qsgtexturematerial.cpp(49): warning #177: function "isPowerOfTwo" was declared but never referenced
qsgtexture.cpp(84): warning #177: function "isPowerOfTwo" was declared but never referenced
qsgdefaultimagenode.cpp(368): warning #177: function "isPowerOfTwo" was declared but never referenced
Change-Id: I6c96dad3e1236fd33a02232f886ca33fa2b21258
Reviewed-by: Alan Alpert (Personal) <416365416c@gmail.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
From the ListView comment I thought the model had to be derived from
QAbstractListModel, but that's not the case, QAbstractListModel will
work just fine, it just doesn't support specific cases such as trees.
Change-Id: I59305006540ddc049e276cf412571373cbfa6c67
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
| |
Change-Id: I86b6bb9007d268ec039614a1693ecd839901e6d9
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
|
|
|
|
|
|
| |
Change-Id: I6c3bd7bebe3d62d1cfd0fa6334544c9db8398c76
Reviewed-by: Akseli Salovaara <akseli.salovaara@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
|
|
|
|
|
|
|
| |
Change copyrights and license headers from Nokia to Digia
Change-Id: Ie7f5d49ed8235d7a7845ab68f99ad1c220e64d5c
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
| |
Change-Id: Ica7685aefde84ec80d8af7a67541af454de4adce
Reviewed-by: Jerome Pasion <jerome.pasion@nokia.com>
|
|
|
|
|
| |
Change-Id: I8dcc1c3f1d6959eef35a45f920bb37c08100a510
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since multisampling can require a lot of memory, and might not
be supported on some hardware, turn off multisampling and
implement antialiasing in the vertex shader instead. The
alternative method of antialiasing is implemented for Rectangle,
Image, BorderImage and AnimatedImage, and must be explicitly
enabled by setting the new antialiasing property.
Task-number: QTBUG-26268
Change-Id: I39a93d978658a494bf51e9f0fd02d8414eb8be12
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
|
|
|
|
|
|
|
| |
Change-Id: Ib584a45454f6fd2a3c0bfb32a76b19839e4a2a09
Reviewed-by: Kim M. Kalland <kim.kalland@nokia.com>
Reviewed-by: Chris Adams <christopher.adams@nokia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Symbols beginning with QDeclarative are already exported
by the quick1 module.
Users can apply the bin/rename-qtdeclarative-symbols.sh
script to modify client code using the previous names of the
renamed symbols.
Task-number: QTBUG-23737
Change-Id: Ifaa482663767634931e8711a8e9bf6e404859e66
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
|
|
|
|
|
|
|
|
|
| |
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: If39bd256b0fa85eba17ea30f8ab87ea27d758908
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
|
|
|
|
|
|
|
| |
Replace Nokia contact email address with Qt Project website.
Change-Id: I6a730abc0c396fb545a48b2d6938abedac2e3f1c
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
Reviewed-by: Alan Alpert <alan.alpert@nokia.com>
|
|
|
|
|
|
|
|
| |
Update copyright headers from before 2011, and a couple of new ones that
were merged after the previous change to copyright headers.
Change-Id: Ia76e08e2734afa4ef3f1207dbcda5ff3bc81b366
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
|
This change moves the QtQuick 2 types and C++ API (including
SceneGraph) to a new module (AKA library), QtQuick.
99% of this change is moving files from src/declarative to
src/quick, and from tests/auto/declarative to
tests/auto/qtquick2.
The loading of QtQuick 2 ("import QtQuick 2.0") is now delegated to
a plugin, src/imports/qtquick2, just like it's done for QtQuick 1.
All tools, examples, and tests that use QtQuick C++ API have gotten
"QT += quick" or "QT += quick-private" added to their .pro file.
A few additional internal QtDeclarative classes had to be exported
(via Q_DECLARATIVE_PRIVATE_EXPORT) since they're needed by the
QtQuick 2 implementation.
The old header locations (e.g. QtDeclarative/qquickitem.h) will
still be supported for some time, but will produce compile-time
warnings. (To avoid the QtQuick implementation using the
compatibility headers (since QtDeclarative's includepath comes
first), a few include statements were modified, e.g. from
"#include <qsgnode.h>" to "#include <QtQuick/qsgnode.h>".)
There's a change in qtbase that automatically adds QtQuick to the
module list if QtDeclarative is used. Together with the compatibility
headers, this should help reduce the migration pain for existing
projects.
In theory, simply getting an existing QtDeclarative-based project
to compile and link shouldn't require any changes for now -- but
porting to the new scheme is of course recommended, and will
eventually become mandatory.
Task-number: QTBUG-22889
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Change-Id: Ia52be9373172ba2f37e7623231ecb060316c96a7
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@nokia.com>
|