| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add one more PerformanceLevel which is similar to Color, except it
draws using triangles instead of points. This is optimal for d3d11
which doesn't support VertexShaderPointSize.
Also rename first levels to *Point to be clear.
Testing this on my windows laptop shows ~15% decrease in RAM usage
for imageparticle/colored example.
Task-number: QTBUG-88294
Change-Id: Ib93bc9fd0d2ef4f1cb8e0d9dcba0db652f288398
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Minor improvements while going through the particles sources:
- Reduce getShadowDatum() calls
- Remove unused m_lastLevel, reloadColor(), m_available
m_velocityFromMovement, maximumAlive, m_pending, m_lastT,
m_last_last_last_emitter, modelIndex
- Color4ub structs can be assigned directly
- Fix pri for shaders_ng files
- Other minor refactoring
Task-number: QTBUG-88124
Change-Id: I5768fed9f4b6379a698849c23436fa38169833a4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
|
|
|
|
|
|
|
| |
The implementation is intertwined with the direct GL path and not
really portable to RHI.
Fixes: QTBUG-78574
Change-Id: I6ac8707544c19a24661f07e0e6d2fc405e49cbff
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an affector acts on a particle, it will add it to a set
of "seen" particles. This means an allocation, per particle,
per frame.
In Qt 6 the problem is less dramatic due to the new QHash
implementation, which uses "wider" buckets, but in Qt 5 this is
hundreds of memory allocations (and deallocations) per frame.
Just reimplement a minimal flat-set API for this use case,
and replace the QSet usages with it. On a testcase with
200 active particles, this reduces memory allocations from
~20'000 per second to 0 when the scene is "stable".
Pick-to: 5.15
Change-Id: I4be1e12a23b8dffca91955148532db243e383a4c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
| |
Change-Id: I334603209818a8030ddb5b5b316cab596c328bf1
Reviewed-by: Lars Knoll <lars.knoll@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>
|
| |
|
|
|
| |
Change-Id: Ifc48b73a2fbfda22d3c4419cb34dd5307107f688
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
QtQuick clients that do not use particles features should not have
to load these classes.
Task-number: QTBUG-25178
Change-Id: Ib15f7655dc4d821595e06f9160d2770375279027
Reviewed-by: Glenn Watson <glenn.watson@nokia.com>
|
