https://bugs.kde.org/show_bug.cgi?id=420141

            Bug ID: 420141
           Summary: Gwenview acts slow and leaks memory when
                    zooming/panning images without an alpha channel
           Product: gwenview
           Version: 19.12.3
          Platform: Neon Packages
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: gwenview-bugs-n...@kde.org
          Reporter: tyna...@gmail.com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to