| Summary: | Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel when display color space conversion is enabled | ||
|---|---|---|---|
| Product: | [Applications] gwenview | Reporter: | Colin Griffith <tynach2> |
| Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | nate, tynach2 |
| Priority: | NOR | ||
| Version First Reported In: | 21.12.0 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Colin Griffith
2020-04-15 22:34:31 UTC
Couldn't reproduce a memory leak, neither in windowed mode, nor in fullscreen mode; tested with JPEG images (these for sure don't have an alpha channel) with Gwenview master version and Qt 5.14.1. I suggest to use a memory profiling tool, such as valgrind or heaptrack; leaks might be caused by the video driver. (In reply to Christoph Feck from comment #1) > Couldn't reproduce a memory leak, neither in windowed mode, nor in > fullscreen mode; tested with JPEG images (these for sure don't have an alpha > channel) with Gwenview master version and Qt 5.14.1. > > I suggest to use a memory profiling tool, such as valgrind or heaptrack; > leaks might be caused by the video driver. What GPU driver do you have? Do you see sluggish behavior, or is it smooth? I've gone ahead and tested it in Xephyr, and it seems smooth and without memory leaks. However, this remained true when I added the '+igpu' and '-glamaor' parameters to Xephyr. So it doesn't seem to be a GLAMOR bug, unlike the slowness within TKGate (which persists within Xephyr with either of those parameters). Since upgrading to 20.04, this no longer occurs. Not 100% sure it's gone and I've not extensively tested it, but I at least no longer have really horribly sluggish behavior when looking at .jpg files. Well that's good. Thanks! Let's call it fixed. :) Unfortunately, I've noticed this behavior has returned. I don't know exactly when, but currently I'm on Gwenview version 20.12.2. At first I thought maybe it was because I used the Oibaf PPA to get bleeding edge GPU drivers, so I just finished purging that repository to return to the version of the Mesa drivers that come with Ubuntu's base packages. After rebooting, the problem has still persisted. Updated system info: Operating System: KDE neon 5.21 (User Edition) KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.8.0-43-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz Memory: 15.6 GiB of RAM Graphics Processing Unit: ASUSTeK R9 290X DirectCU II OC OpenGL Renderer: AMD Radeon R9 200 Series (HAWAII, DRM 3.38.0, 5.8.0-43-generic, LLVM 11.0.0) OpenGL Core Profile Version: 4.6 (Core Profile) Mesa 20.2.6 Hokay, I should have tried this before, but I think I know the culprit now. This only happens when I UNcheck 'Apply only the profile embedded in the image file'. If I keep that option enabled, the slow-down never happens on any images. If I disable it, images without an alpha channel slow down Gwenview and cause memory to climb out of control. Images With an alpha channel are still fast and do not cause memory usage increases. I have both of my monitors profiled and calibrated, so having that option unchecked allows me to see what images should look like on my monitor. At least now I suppose I can choose between accuracy and speed, but I still don't believe that memory should spiral out of control just by panning around an image or changing which image is being looked at. I'm still having this problem. It's likely not seen by many people because most people don't profile/calibrate their displays with a colorimeter, so don't have display profiles installed (other than standard sRGB and the like). My guess is that however Gwenview interacts with LCMS2 is probably to blame. |