In a Qt Quick application, I want to animate the main window height when I click on a toggle button, in order to show or hide a kind of tray panel. The main form content contains a header frame, a swipe view and a grid view below it.
To reach the desired effect, I added the following animations in my qss code, which are run depending of my toggle button state:
ParallelAnimation
{
id: one_dev_connected_toggle_window_height_increase
running: false
NumberAnimation { target: mainWindow; property: "height"; to: 750; easing.type: Easing.InOutQuad; duration: 500}
}
ParallelAnimation
{
id: one_dev_connected_toggle_window_height_decrease
running: false
NumberAnimation { target: mainWindow; property: "height"; to: 450; easing.type: Easing.InOutQuad; duration: 500}
}
When I try to open the tray, the animation cause a huge flickering on my whole interface. However, when I close the tray, the animation cause no flickering at all, and the effect is smooth, as I expected.
My main window is declared as follow:
ApplicationWindow
{
id: mainWindow
visible: true
width: 700
height: 750
color: "#000000"
title: qsTr("Drag&Drop App")
flags: Qt.Window | Qt.FramelessWindowHint
....
Can someone explain me why I'm facing a such flickering? What should I change to fix it?
First I tried to reproduce your behavior with a small app, which is listed below:
main.cpp
#include <QGuiApplication>
#include <QQmlApplicationEngine>
int main(int argc, char* argv[])
{
QGuiApplication app(argc, argv);
QQmlApplicationEngine engine;
QQmlContext* context = engine.rootContext();
// Adding the following line helps to remove the flickering
app.setAttribute(Qt::ApplicationAttribute::AA_ShareOpenGLContexts, true);
engine.load(QUrl("./data/main.qml"));
return app.exec();
}
main.qml
import QtQuick 2.13
import QtQuick.Controls 2.5
ApplicationWindow {
id: mainWindow
width: 800; height: 1000
title: "Animation Flickers"
visible: true
property bool large:true
MouseArea {
anchors.fill: parent
onClicked: {
if (mainWindow.large) {
decr.start()
} else {
incr.start();
}
mainWindow.large=!mainWindow.large;
}
}
ParallelAnimation
{
id: incr
running: false
NumberAnimation { target: mainWindow; property: "height"; to: 750; easing.type: Easing.InOutQuad; duration: 500}
}
ParallelAnimation
{
id: decr
running: false
NumberAnimation { target: mainWindow; property: "height"; to: 450; easing.type: Easing.InOutQuad; duration: 500}
}
}
Then I activated the application attribute AA_ShareOpenGLContexts and the flickering vanished. There might be many reasons for flickering and this might just remove one reason. I already experienced flickering by a non fitting graphics card driver. You should also consider to run your program on a different machine.
Please report back, if my solution didn't solved your problem.
Playing with the parameters, I finally found an acceptable solution.
Here's what I noticed:
Following the Aleph0's reply, I played around the OpenGL flags. I noticed that using the Qt::ApplicationAttribute::AA_UseOpenGLES flag resolved completely the flickering, however it caused a strange side effect in my case: the height of all components contained in my window became inconsistent while the main form height changed, causing a kind of wobbling during the animation, even with the correct anchoring and min and max height constraints defined.
On my main interface I removed the anchoring and used layouts instead. This resolved the strange wobbling during the height change, and almost all the flicker issues. I tested on different computers with different OS, the flickering appear only rarely in several particular cases.
However the wobbling still appears while the layouts are used if OpenGLES is used.
So replacing anchors by layouts was the solution in my case, even if it works not perfectly. But at least the result is acceptable.
Related
I have a QML application with 2 rectangles: a large rectangle and a small rectangle inside the large one.
The small rectangle is animated and moves inside the large rectangle.
The animation is done by combining 2 NumberAnimation in a SequentialAnimation.
It works well, except that the to property of one of the NumberAnimation can change.
I would except the change of value to be applied immediately.
However, it is not taken into account until the animations are fully stopped and restarted.
Calling stop()/start() or restart() does not do anything.
I need to wait for the animation to actually finish and then start it again.
This can be demonstrated with the following QML code:
import QtQuick
import QtQuick.Controls
import QtQuick.Layouts
Window {
width: 640
height: 480
visible: true
RowLayout {
Rectangle {
id: topRect
width: 400
height: 400
border {
color: "red"
width: 2
}
Rectangle {
id: animatedRectangle
width: 100
height:100
color: "blue"
}
SequentialAnimation{
id: animation
loops: Animation.Infinite
running: cbAnimate.checked
alwaysRunToEnd: true
NumberAnimation {
id: forwardAnimation
target: animatedRectangle
property: "x"
to: sbWidth.value
duration: 2000
}
NumberAnimation {
id: backwardAnimation
target: animatedRectangle
property: "x"
to: 0
duration: 2000
}
}
}
ColumnLayout {
CheckBox {
id: cbAnimate
text: "Animate"
}
SpinBox {
id: sbWidth
value: 300
to: 400
}
SpinBox {
value: forwardAnimation.to
to: 999
}
}
}
}
Start the animation with the checkbox
Change the value of to with sbWidth
See in the other SpinBox that the value of to was changed
Observe that the animation is still using the old value
Stop the animation, wait for the Rectangle to stop moving, Start the animation
Observe that the animation is using the value set in step 2
Isn't there a way to make the animation use the new value of to immediately?
This behavior is particularly painful when a QML element is animated by default and the to value depends on the geometry of Items, as during the creation of the QML scene Qt will create and then resize Items. Meaning that animation started at creation time won't get their values updated during the resize.
TLDR
In this particular case the best solution is to use the workaround suggedted by #stephen-quan: animate a proxy property property real animatedX between 0.0 and 1.0. And then bind the property I want to animate to this animated property and do the extra computation in this binding: x: animatedX * sbWidth.value. Eliminating the need of changing the to property of the animation.
Details
The issue of animations not taking property change into account until restarted is a very old issue. It has been reported numerous times:
PropertyAnimation ignores from/to changes
Changing an Animation
duration has no effect
Since Qt 6.4, the state has slightly improved. Quoting Qt documentation:
Since Qt 6.4, it is possible to set the from, to, duration, and easing properties on a top-level animation while it is running. The animation will take the changes into account on the next loop.
However, it still does not affect the current loop and requires the animation to be top-level. So even with this improvement, I still need to animate a proxy property, ensuring changes are taken into account in real-time.
I made various changes to your sample.
I introduced from: 0 to your first NumberAnimation. This ensures that whenever you stop/start the animation, it will reset. Also, removing alwaysRunToEnd helps with that.
I introduced a new property double val: 0 property which will range from 0.0 to 1.0. This is what I used NumberAnimation on instead of x. The advantage is, we know that the NumberAnimation will happily move from 0.0 to 1.0 and back to 0.0 consistently.
Then, I introduced a formula linking val to x and takes into account of sbWidth.value.
To make it easier to change sbWidth.value I changed it from a SpinBox to a Slider.
import QtQuick
import QtQuick.Controls
import QtQuick.Layouts
Page {
RowLayout {
Rectangle {
id: topRect
width: 400
height: 400
border {
color: "red"
width: 2
}
Rectangle {
id: animatedRectangle
property double val: 0.0
x: val * sbWidth.value
width: 100
height:100
color: "blue"
Label {
anchors.centerIn: parent
text: parent.x.toFixed(2)
color: "white"
}
}
SequentialAnimation{
id: animation
loops: Animation.Infinite
running: cbAnimate.checked
//alwaysRunToEnd: true
NumberAnimation {
id: forwardAnimation
target: animatedRectangle
property: "val"
from: 0
to: 1.0
duration: 2000
}
NumberAnimation {
id: backwardAnimation
target: animatedRectangle
property: "val"
to: 0
duration: 2000
}
}
}
ColumnLayout {
CheckBox {
id: cbAnimate
text: "Animate"
}
Slider {
id: sbWidth
value: 300
from: 100
to: 400
}
Text {
text: sbWidth.value.toFixed(2)
}
}
}
}
You can Try it Online!
I'm currently learning QML and I want to create a top round transparent window.
I've build something that looks like that, but it seems wrong for multiple reason.
Here's my code:
Window {
id: app
visible: true
width: 70
height: 70
flags: Qt.Window | Qt.FramelessWindowHint | Qt.WA_TranslucentBackground
Rectangle {
anchors.fill: parent
radius: parent.width / 2.0
color: "black"
MouseArea {
property point clickPos: "1,1"
anchors.fill: parent
drag.target: parent
onPressed: {
clickPos = Qt.point(mouse.x,mouse.y)
}
onPositionChanged: {
var delta = Qt.point(mouse.x-clickPos.x, mouse.y-clickPos.y)
app.x += delta.x;
app.y += delta.y;
}
onDoubleClicked: app.close()
}
}
}
using these flags in the main :
QQuickWindow::setDefaultAlphaBuffer(true);
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
The main problem is that the background is not transparent.
I think it is because the 'round' rectangle is fully painted !?
I've tried multiple flags (Qt.Tool, Qt.Transparent, ...) but none works.
I was wondering if I started well to do what I want (I think I don't) and what is the best way to do it.
I've seen the clipping property for the qml item but I also see there's performance issues. I don't know if it's a good idea to use that property.
I'm running on Qt 5.10 and Win7 using MSVC as compiler.
Thank you
EDIT: Adding transparent background color to the window
Adding an answer, just so I can post an image to prove to you that all you need is to set the color:
Window {
id: app
visible: true
width: 70
height: 70
flags: Qt.Window | Qt.FramelessWindowHint
color: "#00000000"
Rectangle {
anchors.fill: parent
radius: parent.width / 2.0
color: ma.pressed ? "red" : "black"
MouseArea {
id: ma
property point clickPos: "1,1"
anchors.fill: parent
drag.target: parent
onPressed: {
clickPos = Qt.point(mouse.x,mouse.y)
}
onPositionChanged: {
var delta = Qt.point(mouse.x-clickPos.x, mouse.y-clickPos.y)
app.x += delta.x;
app.y += delta.y;
}
onDoubleClicked: app.close()
}
}
}
And the result:
I didn't use any of the flags you are setting from C++, maybe setDefaultAlphaBuffer() is breaking it for you.
I've figured it out.
Searching more deeply on the net and thx to #dtech, I found this article
It was the exact same problem as me. But without #dtech, I would never have thought about the graphic card problem, which led me to this solution.
It seems that you need to have the aero mode enable on windows in order to be able to use transparency on Qt.
I activated the aero mode and then retried the given solution (the one of #dtech), it works very nice.
EDIT: It's a well known "bug" on Qt
Now that I have the solution, it seems obvious but I didn't think about it before.
Thx everyone
According to Animation documentation in section "Default Animation as Behaviors", they say that
There are several methods of assigning behavior animations to properties.
One of them is that we should be able to use Behaviour without on property but I don't succeed in having it working.
Here is my example code. I have a colored circle, and changing the color should trigger the ColorAnimation but it doesn't
import QtQuick 2.5
import QtQuick.Window 2.2
Window {
visible: true
width: 640
height: 480
title: qsTr("Hello World")
Rectangle {
width: 75; height: 75; radius: width
id: ball
color: "salmon"
Behavior {
ColorAnimation { target: ball; duration: 100 }
}
}
Component.onCompleted: timer.start()
Timer{
id: timer
onTriggered: {ball.color = "blue" }
interval: 1000
}
}
If I add on color, it works. I also tried to add property: "color" into ColorAnimation definition but nothing happens.
After browsing the docs a bit more I do not think there is another way to specify the property for Behaviors in QML, even though the animation docs suggest so.
Behavior is a Property Modifier Type more specific a property value write interceptor. Currently Behavior is the only one, see:
http://doc.qt.io/qt-5/qtqml-cppintegration-definetypes.html
Writing Behavior without the on <property> only defines a new Behavior component. To use it, it must be applied on a property. Code from Qt 5 documentation:
// FadeBehavior.qml
import QtQuick 2.15
Behavior {
...
}
Then use that Behavior:
Text {
FadeBehavior on text {}
}
I need to create moving text on the screen continuously from right to left, I have implemented it using QML Timer and Text element.
The below code works fine but I am concerned about the below code causing more cpu or memory usage mainly because the timer is triggered every 33 ms. I have to use this in my places in my application and in multiple instances, like inside many grid windows.
Is this right approach? or does anything exist better than this?
Rectangle{
width:parent.width
height:parent.height
color: "#333333"
Timer {
id: resetTimer
interval: 33
repeat: true
running: true
onTriggered: {
console.log("triggred");
moving_text.x = moving_text.x-1
if(moving_text.x<-1*moving_text.paintedWidth)
moving_text.x=parent.width
}
}
Text{
id:moving_text
x:parent.width
text:"Moving text"
color: "white"
}
}
Why to make things so complected. You could use NumberAnimation on x as follows:
import QtQuick 2.0
Rectangle{
id: root
width:250
height:250
color: "#333333"
Text{
id:moving_text
x:parent.width
text:"Moving text"
color: "white"
NumberAnimation on x{
from: root.width
to: -1*moving_text.width
loops: Animation.Infinite
duration: 3000
}
}
}
As for your concern about memory and cpu usage, you should compare both the methods and check which one suits you. But my personal recommendation is to use NumberAnimation.
I've tried to implement drag and drop in Qt 5.3 using the new QML types Drag, DragEvent and DropArea. This is the original example from the documentation of the QML Drag type with some small modifications:
import QtQuick 2.2
Item {
width: 800; height: 600
DropArea {
width: 100; height: 100; anchors.centerIn: parent
Rectangle {
anchors.fill: parent
color: parent.containsDrag ? "red" : "green"
}
onEntered: print("entered");
onExited: print("exited");
onDropped: print("dropped");
}
Rectangle {
x: 15; y: 15; width: 30; height: 30; color: "blue"
Drag.active: dragArea.drag.active
// Drag.dragType: Drag.Automatic
Drag.onDragStarted: print("drag started");
Drag.onDragFinished: print("drag finished");
MouseArea {
id: dragArea
anchors.fill: parent
drag.target: parent
}
}
}
Expected behaviour: The small blue rectangle (drag target) can be dragged around with the mouse. If dragged over the larger green rectangle in the center of the window, this rectangle turns red and back to green when leaving. In addition, the signals dragStarted, entered, exited, dropped and dragFinished are emitted in time and the corresponding signal handlers print out their messages.
Experienced behaviour:
Depends on Drag.dragType (see commented line above):
Drag.dragType is NOT set (default is Drag.Internal):
Drag and drop works as described, but only the signals entered and exited are emitted. The other signals (dragStarted, dragFinished and dropped) are suppressed. So there is no way to react to the drop in the DropArea.
Drag.dragType is set to Drag.Automatic:
All of the signals are emitted now, but the blue rectangle (drag target) does not move with the mouse. Instead, the mouse cursor changes its shape to visualize possible drop targets. After the mouse has been released, the blue rectangle jumps to the latest mouse position.
Neither of these two variants are pleasing. How can I get all signals and still be able to drag around the drag target? Unfortunately the documentation is everything but clear about drag-and-drop in QML, especially about the ominous Drag.dragType.
If you open the QQuickDrag source code and look at the differences between start(), which is used by Drag.Internal, and startDrag() which is used by Drag.Automatic, the difference is pretty obvious. start() sets up an event change listener, which it then uses to update the position of the attached object. startDrag() doesn't do this.
Why does it work this way? I have no idea! The QtQuick 2 drag and drop documentation certainly has room for improvement here.
There is a fairly simple workaround: take the best from both worlds. Use Drag.Automatic, but instead of setting Drag.active, call start() and drop() manually. It won't invoke Drag.onDragStarted() and Drag.onDragFinished() but you essentially get those for free anyway by listening for a change in the MouseArea's drag.active.
Here's the concept in action:
import QtQuick 2.0
Item {
width: 800; height: 600
DropArea {
width: 100; height: 100; anchors.centerIn: parent
Rectangle {
anchors.fill: parent
color: parent.containsDrag ? "red" : "green"
}
onEntered: print("entered");
onExited: print("exited");
onDropped: print("dropped");
}
Rectangle {
x: 15; y: 15; width: 30; height: 30; color: "blue"
// I've added this property for simplicity's sake.
property bool dragActive: dragArea.drag.active
// This can be used to get event info for drag starts and
// stops instead of onDragStarted/onDragFinished, since
// those will neer be called if we don't use Drag.active
onDragActiveChanged: {
if (dragActive) {
print("drag started")
Drag.start();
} else {
print("drag finished")
Drag.drop();
}
}
Drag.dragType: Drag.Automatic
// These are now handled above.
//Drag.onDragStarted: print("drag started");
//Drag.onDragFinished: print("drag finished");
MouseArea {
id: dragArea
anchors.fill: parent
drag.target: parent
}
}
}
I realize it's not a completely satisfying solution, but it does match your expected behavior.
This solution offers:
Notifications for all of the desired events: drag started, drag finished, enter drag area, exit drag area, and dropped in drag area.
The drag animation is automatically handled by QtQuick. The square doesn't freeze in place like it does when running the sample code with Drag.Automatic.
What it doesn't offer:
An explanation as to why QtQuick's drag and drop functionality works this way, or whether it's even the intended behavior by the developers. The current documentation seems ambiguous.
Just ran into this myself (using Qt 5.2, but the same problem exists there). I've got a 'slider box' on the X-axis and just wanted to know when the drag was finished... instead of responding to every position change along the way. My workaround involved hacking the states/transitions, with a ScriptAction to provide the logic. This is the simplified version for mimicking a response to the "onDragFinished" signal. So while it doesn't cover all your drag/drop signals, it might get you pointed in the right direction.
Rectangle {
id: sliderControl
height: coordinates.height
width: 80
color: "#F78181"
border.color: "#FE2E2E"
border.width: 1
opacity: 0.4
MouseArea {
id: mouseArea
anchors.fill: parent
drag.target: sliderControl
drag.axis: Drag.XAxis
drag.minimumX: 0
drag.maximumX: view.width - sliderControl.width
hoverEnabled: true
}
states: [
State {
name: "dragging"
when: mouseArea.drag.active
},
State {
name: "finished_dragging"
when: !mouseArea.drag.active
}
]
transitions: [
Transition {
from: "dragging"
to: "finished_dragging"
ScriptAction {
script: console.log("finished dragging script");
}
}
]
}
ps - I know that such a 'workaround' doesn't qualify for the bounty parameters, but I was pretty bummed to find only your question (no solutions) when I searched for help on the issue. Hopefully anyone else stumbling down this path will find this useful. Unfortunately, I've got no clue what's going on with QML's Drag.dragType either.