Gwenview hangs when working with a directory filled with typical images (pngs, jpegs) or movies (avis) and large grayscale, 16 bit TIFF stacks (2 GB). The TIFF stack is about 250 images 2048x2048. Removing the large TIFF files from the directory fixes the hangs. The hang occurs when the next image (using the "Go to next image" button is a large TIFF file. It will actually hang before finishing drawing the current image while reading the big TIFF file from disk. Gwenview will unfreeze when the read from disk is finished. Additionally since gwenview is reading the entire large TIFF file into memory it consumes 2 GB (or whatever the size of the TIFF file is) momentarily until the TIFF is finished reading then it drops down to a more reasonable 80 MB. The reason this is a bug is because Gwenview does not display my TIFF stack as a movie, but rather it only shows the first image of the stack and should therefore only read the first image of the stack from disk. I think Gwenview would also benefit from performing the prefetch asynchronously in the background as I imagine that would benefit others who have very static (say gigapixels) TIFF images. Additionally I think it would be helpful to have more control over what types of files Gwenview will display. In my case I actually do not want to view my TIFF stacks in Gwenview and would prefer hitting the next button would skip right over them.
Thanks for your report, although in general it's best to only report one issue per bug. Regarding your points: 1. High memory usage for TIFF stack: I could not find anything specifically about TIFFs in Gwenview's sources, so that functionality is probably coming from https://doc.qt.io/qt-5.10/qtimageformats-index.html. Try opening a bug over there. 2. Display TIFF stack as a movie: Is there a format specification for that? If so, it would perhaps make sense to suggest adding support for that in Qt (e.g. similar to GIFs) or libVLC/GStreamer (e.g. similar to MP4s). 3. Better filtering capabilities for various filetypes: Currently you can toggle showing of videos, but more control would certainly be nice. Try searching for an existing bug on that, otherwise feel free to open a new bug. 4. Preloading the next image hangs loading of the current image: Sounds more like a bug to me, as in general I'd expect loading of the current image to finish first. Needs a fix, but moving to asynchronous preloading would certainly be nice too, in order to take advantage of multicore CPUs and display the next image even faster. (See also Bug 71870). Let's make your bug strictly about problem #4. (In case you feel like sending a patch to solve this sooner rather than waiting for others to do it later, let us know if you need help getting started.)
Oh you are right I listed way too many things for one bug report. I apologize and thanks for parsing through and itemizing them. I have a couple of things to add. 4. I would like to clarify that the next image starts loading and gets stuck in the middle of the transition animation so I end up seeing the previous image and next image superimposed. But there is still a bug here. I think gwenview should wait until the transition animation finishes to start pre-loading the next image. I'm not sure where else to reply to your number 2 since it is now off-topic, but I hope you don't mind my reply here: 2. I do not believe there is a format specification for displaying TIFF stacks as movies. The TIFF specification is basically like a directory structure so it can contain many images of different types mixing sizes, bit depths, byte orders, color/grayscale, lossless compression, and even storing jpegs as well in what are called pages. Pages have no need to be related. Even for related pages in a multi-page TIFF there is no standard for storing the desired framerate for playback. So I think the best way to deal with viewing TIFF files in a software like gwenview would be to either just show the first image or have another slider pop up for multi-page tiffs to browse through the pages.
As an update to this bug. If the transition is disabled by setting "Animations" to "None", the next image is display fully before the preloading of the next image begins. It is only when "Animations" is set to "Software" or "OpenGL" that the animation is frozen mid-transition upon which gwenview waits for the preload to finish before finishing the transition animation.
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!