| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Accelerated graphics is now possible without OpenGL support. With
this change, a Qt build with -no-opengl can still run Qt Quick with
a Vulkan, Metal, or Direct3D backend.
Fixes: QTBUG-84027
Change-Id: Ib63c733d28cfdf7de16b138df136fa7628e1747b
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
|
|
|
|
|
| |
Do not leave them in quick/items' qrc.
Change-Id: I12360a54caa368219a7a80645f92af66aa9de9ba
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Most core Qt Quick items use one of the nodes provided by the Scenegraph
Adaptation Layer, however the two items that provide support for Sprites
created their own custom nodes. There was significant redundancy in
this, and it made it only possible to use the OpenGL adaptation. The
AnimatedSprite and SpriteSequence items have been cleaned up, and now
use the new QSGSpriteNode.
Change-Id: Idc20b9c5da9dc1c94f6368021785382cdf7cec5a
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The basic approach is to have the batched renderer create and bind a
vertex array object if it detects we are using an OpenGL Core profile
context. The VAO is bound for the duration of the QQ2 renderer's
work cycle and unbound at the end so as to not interfere with any
other VAO's a user may wish to use.
All shaders have been copied and ported to be compliant with the
GLSL 150 core specification which is the minimum for a Core profile
context (OpenGL 3.2 Core). We are not using any newer features as
yet so this will work anywhere we can get a Core profile context.
The QSGShaderSourceBuilder class has been extended to resolve any
requests for shaders to the same basefilename with "_core"
appended prior to any file extension. This could be extended in
the future to allow version, or GPU or platform specific shaders.
The QSGShaderSourceBuilder has also been extended to allow it to
insert #define definitions in the prologue of a shader. Any such
definition is inserted:
* After the last #extension directive (if any are found)
* Otherwise after the #version directive (if found)
* Otherwise at the start of the shader source
This is required by the custom particle shaders which make
extensive use of such #defines.
In addition the mechanism used by the distance field glyph cache to
extend the cache with new glyphs has been modified to work (and
work more efficiently) when using a Core profile context.
Rather than using a shader program and a buffer filling quad to
blit the old texture into the new cache texture, we instead use
the technique of framebuffer blitting. The existing fallback
implementation using glTexSubImage2D() is still available if
needed.
The DECLARATIVE_EXAMPLE_MAIN macro has been extended to allow easy
testing of any of the QtDeclarative examples with a core profile
context. Just run the example with
QT_QUICK_CORE_PROFILE=1 ./text
for e.g. The only ones that may not work out of the box are those
that provide GLSL shader source e.g. the customparticles or
shader effect examples. These work fine if the shader source is
adapted to GLSL 150 core.
In the future it may be a good idea to expose some context property
to QML that the user can use to determine what shader source
variation to provide to Qt Quick. Along these lines it would also
be very nice to allow the provision of shader source to
ShaderEffect or CustomParticle from a separate source file just as
we now do within Qt Quick.
Task-number: QTBUG-32050
Change-Id: Ia6e9f06dbb8508af9ae03c6b60fb418b4cc9e41f
Reviewed-by: Lars Knoll <lars.knoll@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>
|
