SUMMARY Gwenview is sluggish and leaks memory constantly when viewing images which lack an alpha channel. Memory increases every time any operation is performed, such as panning/zooming the view, or the next frame of a gif being rendered. STEPS TO REPRODUCE 1. Open the system monitor (I use KSysGuard) and filter process names to only show Gwenview. 2. Open an image that lacks an alpha channel. 3. Zoom in on the image so that you can pan, and observe that RAM usage increases. 4. Pan around the image, and observe that RAM usage increases. 5. Switch to an image with an alpha channel. Note that RAM usage does not decrease. 6. Zoom in on the image so that you can pan, and observe that RAM usage stays constant. 7. Pan around the image, and observe that RAM usage stays constant. OBSERVED RESULT Every time you zoom or pan the image, the operation is sluggish and at a low framerate... And Gwenview's memory consumption gets higher. The slowdown is particularly noticeable when panning. Note that this does not happen when you switch to viewing an image with an alpha channel - RAM usage stays constant (but does not go down), and panning around the image is incredibly fast and smooth. EXPECTED RESULT The same behavior that is observed when viewing images with an alpha channel - constant RAM usage, and smooth panning/zooming. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.18 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.1 Kernel Version: 5.3.0-46-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.33.0, 5.3.0-46-generic, LLVM 10.0.0) OpenGL Core Profile Version: 4.6 (Core Profile) Mesa 20.0.0-devel - padoka PPA ADDITIONAL INFORMATION This happens whether I have 'Animations' (in the 'Image View' settings) set to 'OpenGL', 'Software', or 'None'. Images with an alpha channel are smooth regardless of whether or not the image actually has any transparent (or semi-transparent) pixels. Given the reliance on an alpha channel, I'm going to guess that the image data is getting converted from an array of RGB bytes (each structure being 24 bits wide, and thus not 32-bit aligned) to a 32-bit aligned RGBA array, each pixel being 4 bytes instead of 3 bytes... And this operation is being done every time zooming and panning occurs. I'm guessing that one of either the converted, or the temporary non-converted, version of the pixmap is not being destructed/freed properly. It's also worth mentioning that animated .gif files that have a color reserved for transparent pixels play smoothly and do not cause increased RAM usage over time, while viewing an animated .gif file which does not reserve a color for transparency play back sluggishly and increase RAM usage with each frame that gets displayed. This bug has bothered me for YEARS now. I would have thought it would be reported by now, but I've only seen tangentially related reports (like 'leaks memory in fullscreen mode', 'when viewing lots of files', etc.) when searching for what to follow. Many bugs have reportedly been fixed years ago, but I still see their effects now with current versions, but only with some images - images without alpha channels. I have a feeling that many of the memory leak or slowdown bugs are actually just this one bug dealing with non-alpha-channel images.
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.