| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QSignalMapper ought to be deprecated soon.
It simplifies the code, too.
There is still one use in QQuickGenericShaderEffect which is a bit complicated
to get rid of. A very similar use of QSignalMapper was in use in
QQuickOpenGLShaderEffectCommon but was removed in commit 8c745d80, the same
should be done for QQuickGenericShaderEffect.
(Note the QueuedConnection in qquickparticlesystem is there because the
QSignalMapper used to be in the main thread, meaning a round-trip via the
event loop)
Change-Id: I331b787becbad37f717035bf119bafd7a7214630
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
| |
|
|
|
|
| |
Change-Id: I4e7fd5e9781dec7ee6ed8807ca1a51c937f6f9f3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A use-after-free would occur if the sender of a connection would
disconnect (and destroy the slot object), and then the receiver would
try to clean-up and access the slot object again. The fix is to have
the receiver take out a reference to the slot object, because it will
manage the life-time, and thus delete the slot object when it doesn't
need it anymore.
Change-Id: Ie2033cfb7212acceb2c2cd0bd9e7e45c2dd5e434
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Don't use a signal mapper, but handle the mapping using a custom slot
object and a lambda to do the dispatching ourselves.
- Don't do meta-calls by property name, but by index.
- Cache the meta-object.
- Resolve the property indices by using the QML property cache.
For a shader with 6 property connections, the time spent goes from 320k
instructions to 80k instructions (valgrind on x86_64).
Task-number: QTBUG-53901
Change-Id: I2809198cf62f9716b3683798222203fc3e97fbb3
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
|
| |
|
|
|
|
|
|
|
|
|
| |
Similarly to what we do with "hlsl" in the D3D12 backend, we can use
"glslcore" to provide a file-based alternative to the GraphcsInfo or
OpenGLInfo-based conditions in the fragmentShader and vertexShader
properties. This is particularly useful in a few places inside Qt,
for example Quick Controls, that have to cater to all possiblities.
Change-Id: I5d89e7b1534afbc323a663869bab7796bd1a337d
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rendererInterface() should not require isSceneGraphInitialized() to be
true - the API and language queries like graphicsApi() have no need for the
scenegraph, they only need the plugin to be loaded, i.e. that the QQuickWindow
is constructed.
This is the key to be able to make GraphicsInfo report graphicsApi and
shaderType with the correct values as early as possible - meaning as soon
as the item is associated with a window. The initialization of the
scenegraph (the exact timing of which varies backend to backend) does not
matter here.
The fragment and vertex shader property setting is now unified in the two
ShaderEffect implementations:
- If the component is complete, the shader is attempted to be processed
right from the setter.
- Otherwise the item will trigger processing once the component is
complete.
- If there is no window when processing is trigerred, it is deferred via
polish.
To implement item polish handling we need a new virtual in
QQuickItemPrivate since we cannot intrdouce virtuals into the public
classes.
This way one can write a condition (and later potentially use file
selectors) like this:
fragmentShader: GraphicsInfo.shaderType == GraphicsInfo.GLSL ? "..." : ...
without having to worry about getting an unintended value processed due to
GraphicsInfo not yet reporting an up-to-date value.
parseLog() forces, for GL at least, shader processing to prevent autotests
from breaking.
Change-Id: If55c69d746c29cd07348ddad2d6b0f2b5dd7f3a2
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
|
|
|
|
| |
which should route and place most of its work into the scenegraph.
And fix a test.
Change-Id: I04f29cba53c2bab62e41b3b524794d3c4d20a472
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Register the common QQuickShaderEffect class as ShaderEffect to QML.
In case of GL this will route to QQuickOpenGLShaderEffect. For others
the default no-op implementation is used (at least for now). Later this
new implementation will route to a backend-specific scenegraph node via
the adaptation layer.
This also means that QQuickOpenGLShaderEffect is no longer a QQuickItem
and QQuickShaderEffect must handle everything item-related and forward.
Change-Id: I1ff4b674253543a04978a69f4a3b67f3a44dd983
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
|
|
|
Rename the C++ sources and classes. The QML type name remains the same.
No changes in functionality.
The shader effect, node, material (and uniform animator and particles and
bits and pieces here and there...) are highly interconnected and do not
follow the usual design practices for Quick and the scenegraph and the
adaptation layer. Therefore while we aim for keeping full compatibility
for GL apps, other backends will likely get a different ShaderEffect item
implementation.
The C++ class QQuickShaderEffect itself is currently a dummy with an
unchanged API. It is not in use for now but forms the basis for the
implementation for other backends. This will be covered in future commits.
Change-Id: Ia39ce4b303f8f33e2f241d11e35fa62423e43127
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
|
