Could you maybe vote on this issue so that the devs could see and investigate stuttering with QMovie and the AnimatedImage QML Type?

Mizmas

https://bugreports.qt.io/browse/QTBUG-133747

Both QMovie and AnimatedImage struggle to play gifs and webp files consistently, the animation stutters, especially when using .webp. It would be helpful if you could vote on this issue so the devs would do something about it.

AnimatedImage uses QMovie internally, so the problem is mainly QMovie.

Pl45m4

@Mizmas

I don't think that this is a Cat. P2 (Important) bug (if any), that needs to be fixed ASAP.
There are a lot of other potential bugs with actually higher priority.
Perhaps it will get an overhaul towards Qt 7, so this behavior is fixed.

BTW: Some of my Android devices have a weird "interpretation" of webp files as well... some webp's are not played at all, some are played in slowMo and some actually appear faster...(but that's not on QMovie, unless the Android Media Gallery is also based on Qt/QML?!)

Mizmas

@Pl45m4 I'm relatively new to Qt, but Qt 7 doesn't seem to be close to release, and how would you know that the Qt team is even aware of the issue?

SGaist

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.

Mizmas

@SGaist It's not my report, but I commented a link to a stackoverflow question with an example

SGaist

@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

@SGaist And what If I'm using PyQt6, would those code examples be ok?

Christian Ehrlicher

@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

@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

Christian Ehrlicher

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.

Mizmas

@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."

Pl45m4

@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

@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

@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