Animated GIFs animation is some milliseconds too slow. Especially if you compare animation speed with major browsers like Chrome or Firefox. Also other image viewers like e.g. Mirage are faster with the animation speed. Reproducible: Always Steps to Reproduce: 1. Open and save image from url: http://i.imgur.com/bmf71.gif 2. Wait till the browser (Firefox or Chrome) loaded the GIF completely. 3. Compare animation speed. This effect is also visible with various other animated GIFs. Actual Results: Firefox, Chrome and Mirage show animated GIF faster. Gwenview is slower. Expected Results: Gwenview and Firefox, Chrome, Mirage have the same GIF animation speed. I'm using the Unity desktop (Ubuntu 11.10), but I've seen this effect also on pure KDE desktops like Kubuntu and also with newer versions of Gwenview.
Still prevalent in gwenview 4.12.0.
*** Bug 367868 has been marked as a duplicate of this bug. ***
Still an issue with a recent Gwenview. More notes: - In Bug 367868 the animation speed seems to depend on the window size. - For me, even Firefox and Chromium have different speeds, i.e. Firefox is faster than Chromium, which is faster than Gwenview. - Might be worth checking whether only Gwenview is affected, or other Qt apps as well.
any notice of this bug? 18.04.0 is still affected
Open a large gif, and Gwenview also skyrockets in RAM usage. It's as if it's keeping every frame in memory, including each loop as new frames it generates instead of reusing them. This is a serious issue.
By the way, by large I mean resolution-wise.
Created attachment 123801 [details] 60 seconds countdown analog clock I've also did some tests here using the attached 60-seconds-countdown.gif file. It really should be 60 seconds in playback length (by ImageMagick): $ identify -format ' + %T' 60-seconds-countdown.gif | sed 's/^/(0/; s/$/) \/ 100\n/' | bc -l 60.00000000000000000000 However, with Gwenview (up to 19.04.3), I got the following playback times (manually tracked, not precise to the deci-second) related to Gwenview window resolution: 256x256 - 01:20 (probably due to additional scaling) 512x512 - 01:16 1024x1024 - 01:30 2560x1600 - 03:45 Another thing I noticed was that reloading/restarting the GIF (using F5 key) the playback speed slowed down even more and the CPU usage went up. After 10 reloads, gwenview was using ~80% of a single CPU core and slowed down playback from ~01:30 initially to ~05:24 (at 1024x1024 window size), after 20 reloads to ~09:20 at ~88).
I'm now relatively convinced that this is, in part, caused by bug 420141 (which I just filed today). However, I'm noticing that even on gifs with alpha transparency, there's STILL a small amount of slowdown - just not nearly as much. So while I think that bug helps get to the root of the problem, there's still something else going on here.
If I open gwenview, then open several gifs successively, I don’t observe any memory leak (at least not anything easily noticeable). However, any gif is played really slowly (Gwenview 20.04.0, Arch Linux).
I'm on Manjaro with Gwenview 20.04.3. This one gets more interesting. If I launch a gif from, lets say, Dolphin then it is slow. But other then that, every time I load a gif for the first time, it runs fine. For example, when I go to the next gif (arror keys or the 'next' button) or launch a gif from Gwenview explorer view. This works only once, because if I go back to the same gif (even with arrows, or explorer view) it's slow now.
As of Gwenview 19.12.3, this bug is still present. While launching the 60 second clock gif image in a correctly behaving player (here Firefox 90.0.2, or Nomacs 3.12) and Gwenview at the same time, the result is that it's not just some milliseconds behind, but twice as slow.