Could you maybe vote on this issue so that the devs could see and investigate stuttering with QMovie and the AnimatedImage QML Type?
-
Hi,
The speed of gif is a pretty complex matter and it's not easy to make work for all possible files. I don't know the current webp implementation.
You should provide sample files and a complete minimal compilable project on that bug report so help things out.
-
@SGaist It's not my report, but I commented a link to a stackoverflow question with an example
-
@Mizmas It does not matter that it's not yours, you can improve it.
I would recommend adding the example to the report because linked example can disappear. -
@Mizmas said in Could you maybe vote on this issue so that the devs could see and investigate stuttering with QMovie and the AnimatedImage QML Type?:
would those code examples be ok?
At least it would prevent me from investigating it...
Also the bug report is very vague - there is no measurement or anything which confirms it. I would expect a proper timing output to proove the statement. -
@Mizmas said in Could you maybe vote on this issue so that the devs could see and investigate stuttering with QMovie and the AnimatedImage QML Type?:
would those code examples be ok?
At least it would prevent me from investigating it...
Also the bug report is very vague - there is no measurement or anything which confirms it. I would expect a proper timing output to proove the statement.@Christian-Ehrlicher You don't really need any measurements as it's quite obvious with .webp files both with AnimatedImage and QMovie
Left - played in browser, right - played with QMovie, but it's the same result with AnimatedImage
-
No reproducer in c++ - no help from my side. This was the only thing I said. If you want help for such a minor bug you have to provide also some help.
-
No reproducer in c++ - no help from my side. This was the only thing I said. If you want help for such a minor bug you have to provide also some help.
@Christian-Ehrlicher I'm sorry, but I have never done C++ OOP, but the issue is as simple as
movie = QMovie("path_to_movie") movie.setCacheMode(QMovie.CacheMode.CacheAll) label = QLabel() label.setMovie(movie) movie.start()And you can clearly see the the stuttering when using any .webp file, and some stuttering with .gif
The issue is described in detail on stackoverflow here https://stackoverflow.com/questions/79672044/qmovie-is-stuttering-lagging-when-using-an-animated-webp-file-on-both-pyqt6-a
"QMovie has a relatively simple implementation based on some arbitrary assumptions, and treats all animated image formats in the same way.
Specifically, it adjusts the "next frame delay" only based on the time needed to load the current frame, considering what the underlying QImageLoader tells it: if the next frame should be presented after 30ms and loading the image will take 25ms, it will then set (but not actually schedule) the next frame after 25ms.Once the new frame has been loaded, QMovie emits its updated() signal, which eventually calls all the connected slots (including the internal one used by QLabel), and finally starts the timer with the interval considered above.
The problem with this is that those slots are normally connected using a direct connection, meaning that every function connected to the signal will be blocking until it has returned. The result is that the update doesn't consider the possible overhead caused by those functions the event loop, therefore a QMovie will always be slower than the sum of the declared duration of each frame, because it will begin to schedule the next frame only after the event loop allows it.
The actual implementation can be seen in the source code (look for the void QMoviePrivate::_q_loadNextFrame(bool starting) line).
There is an actual bug report about this (QTBUG-133747), it was reported for 6.8.2, but the source of the problem obviously comes from much earlier versions, and there has been no activity on that report since its submission.
In my opinion, I sincerely doubt this will ever be fixed, unless extreme inconsistencies will be found and reported: image animations don't commonly require such a precise accuracy (since there's usually no need for syncing) and the Qt developer team certainly has more important priorities. Yet, you could still consider to sign up the Qt bug report system and vote that bug." -
@Christian-Ehrlicher I'm sorry, but I have never done C++ OOP, but the issue is as simple as
movie = QMovie("path_to_movie") movie.setCacheMode(QMovie.CacheMode.CacheAll) label = QLabel() label.setMovie(movie) movie.start()And you can clearly see the the stuttering when using any .webp file, and some stuttering with .gif
The issue is described in detail on stackoverflow here https://stackoverflow.com/questions/79672044/qmovie-is-stuttering-lagging-when-using-an-animated-webp-file-on-both-pyqt6-a
"QMovie has a relatively simple implementation based on some arbitrary assumptions, and treats all animated image formats in the same way.
Specifically, it adjusts the "next frame delay" only based on the time needed to load the current frame, considering what the underlying QImageLoader tells it: if the next frame should be presented after 30ms and loading the image will take 25ms, it will then set (but not actually schedule) the next frame after 25ms.Once the new frame has been loaded, QMovie emits its updated() signal, which eventually calls all the connected slots (including the internal one used by QLabel), and finally starts the timer with the interval considered above.
The problem with this is that those slots are normally connected using a direct connection, meaning that every function connected to the signal will be blocking until it has returned. The result is that the update doesn't consider the possible overhead caused by those functions the event loop, therefore a QMovie will always be slower than the sum of the declared duration of each frame, because it will begin to schedule the next frame only after the event loop allows it.
The actual implementation can be seen in the source code (look for the void QMoviePrivate::_q_loadNextFrame(bool starting) line).
There is an actual bug report about this (QTBUG-133747), it was reported for 6.8.2, but the source of the problem obviously comes from much earlier versions, and there has been no activity on that report since its submission.
In my opinion, I sincerely doubt this will ever be fixed, unless extreme inconsistencies will be found and reported: image animations don't commonly require such a precise accuracy (since there's usually no need for syncing) and the Qt developer team certainly has more important priorities. Yet, you could still consider to sign up the Qt bug report system and vote that bug."@Mizmas said in Could you maybe vote on this issue so that the devs could see and investigate stuttering with QMovie and the AnimatedImage QML Type?:
the Qt developer team certainly has more important priorities
That's what I said :))
If you find a solution, feel free to provide a patch and submit it. They will review it and accept it, if the fix is reasonable. Then the correct behavior (if there's something wrong) will be implemented much earlier. Maybe in Qt 6.11 oder something.
-
@Christian-Ehrlicher I'm sorry, but I have never done C++ OOP, but the issue is as simple as
movie = QMovie("path_to_movie") movie.setCacheMode(QMovie.CacheMode.CacheAll) label = QLabel() label.setMovie(movie) movie.start()And you can clearly see the the stuttering when using any .webp file, and some stuttering with .gif
The issue is described in detail on stackoverflow here https://stackoverflow.com/questions/79672044/qmovie-is-stuttering-lagging-when-using-an-animated-webp-file-on-both-pyqt6-a
"QMovie has a relatively simple implementation based on some arbitrary assumptions, and treats all animated image formats in the same way.
Specifically, it adjusts the "next frame delay" only based on the time needed to load the current frame, considering what the underlying QImageLoader tells it: if the next frame should be presented after 30ms and loading the image will take 25ms, it will then set (but not actually schedule) the next frame after 25ms.Once the new frame has been loaded, QMovie emits its updated() signal, which eventually calls all the connected slots (including the internal one used by QLabel), and finally starts the timer with the interval considered above.
The problem with this is that those slots are normally connected using a direct connection, meaning that every function connected to the signal will be blocking until it has returned. The result is that the update doesn't consider the possible overhead caused by those functions the event loop, therefore a QMovie will always be slower than the sum of the declared duration of each frame, because it will begin to schedule the next frame only after the event loop allows it.
The actual implementation can be seen in the source code (look for the void QMoviePrivate::_q_loadNextFrame(bool starting) line).
There is an actual bug report about this (QTBUG-133747), it was reported for 6.8.2, but the source of the problem obviously comes from much earlier versions, and there has been no activity on that report since its submission.
In my opinion, I sincerely doubt this will ever be fixed, unless extreme inconsistencies will be found and reported: image animations don't commonly require such a precise accuracy (since there's usually no need for syncing) and the Qt developer team certainly has more important priorities. Yet, you could still consider to sign up the Qt bug report system and vote that bug."@Mizmas said in Could you maybe vote on this issue so that the devs could see and investigate stuttering with QMovie and the AnimatedImage QML Type?:
. Yet, you could still consider to sign up the Qt bug report system and vote that bug."
I just gave you hints on how to speed up the debugging for the developer and so maybe also for me. I will not start building a c++ test app by myself and I think others do the same. We need a minimal, compileable example, preferably in c++. Since you don't provide one, the chances that it will be fixed are lower. I will not look into it until the requirements are not met. I even think about setting the bug to 'need more information' as there is no mre ...
-
@Mizmas said in Could you maybe vote on this issue so that the devs could see and investigate stuttering with QMovie and the AnimatedImage QML Type?:
the Qt developer team certainly has more important priorities
That's what I said :))
If you find a solution, feel free to provide a patch and submit it. They will review it and accept it, if the fix is reasonable. Then the correct behavior (if there's something wrong) will be implemented much earlier. Maybe in Qt 6.11 oder something.
@Pl45m4 I'm too stupid to fix it myself, and like I said, no experience with C++ OOP, only with microcontrollers.
Explain me this though, wouldn't QMovie and AnimatedImage be one of the most popular QObjects, since it allows you to use custom asset animations to create your own widgets with different states, for example here's one using a single .gif file for cursor hover/exit:
It's a lot easier to do stuff in animation programs, then to, for example, create a cavalier projection algorithm for Qt, to get this extrusion animation
