| Summary: | Gwenview hangs whenever a large TIFF stacks is next "image" to display | ||
|---|---|---|---|
| Product: | [Applications] gwenview | Reporter: | Kieran Ramos <ramos.kieran> |
| Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | null |
| Priority: | NOR | ||
| Version First Reported In: | 18.04.0 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Kieran Ramos
2018-05-03 18:22:22 UTC
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! |