Bug 2156 - memory chewed up (especially in Gimp-Gap)
Summary: memory chewed up (especially in Gimp-Gap)
Status: RESOLVED DUPLICATE of bug 1043
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xorg (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-26 22:55 UTC by spamless
Modified: 2005-12-24 23:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description spamless 2004-12-26 22:55:50 UTC
I am glad to see that kernels 2.6.9 and 2.6.10 showed the problems in xorg's
i810(E) driver and that 6.8.2RC1 (6.8.1.901) works half-way with kernel
2.6.10 and have hopes that by version 6.8.2 I, too, will be able to see why
Gimp 2 is considered better than Gimp 1.2.5.

I built binary rpms from Fedora/Rawhide xorg-x11-6.8.1.901-1.src.rpm and
installed in Fedora Core2, kernel 2.6.10. And much to my surprise, I could
start X!

However, the bug that has been reported before, still rears its head - the
i810(E) driver refuses to release memory.

I use gimp for gimp-gap. Simple animations. A set of frames, move-path and
simply move one object (or animation) over another. I open a project, use
move-path and move an item over the frames. Then check with "free" to see
that memory has been used by the operation and is not freed. Do it again.
Small frames, small item, and more memory used. After the third small edit,
I am out of ram (256 Meg) and buffers and into swap and the memory is not
freed. Time to save the project. Then close gimp - which takes 10-20
minutes. Memory is still not freed. One has to close down X and the i810(E)
driver to get the memory back.

So, I could work in gimp 2.2 by:

 Start X
 Start Gimp
 Load project
 Make 1-3 edits.
 Save project.
 Close Gimp (~15 minutes)
 Close X
 Start X
 Start Gimp
 Load project
 Make 1-3 edits.
 Save project.
 Close Gimp (~15 minutes)
 Close X
 Start X
 Start Gimp
 Load project
 Make 1-3 edits.
 Save project.
 Close Gimp (~15 minutes)
 Close X
 ...

Naturally, this is undoable, so I reboot to RH72, Gimp 1.2.5, XFree, where I
have a working X server for the i810(E) chip and use that.

This bug has been reported before, I believe. Kernels 2.6.9 and 2.6.10 have
shown that the xorg i810(E) driver is bad but is now partly usable in kernel
2.6.10 (the 6.8.2RC1 version of the driver). Is this only a problem with the
i810(E) driver or is it an error to try to use Gimp with xorg's drivers for
any system?

I have hopes that by version 6.8.2 I will finally be able to use Gimp 2.2
but am not holding my breath and will keep the working RH72/Gimp_1.2.5
partition.
Comment 1 sign 2005-02-14 02:19:08 UTC
I have Radeon 7500 mobility with radeon driver and have the same problem.

GIMP 2.2.3
GIMP-GAP 2.0.2
Comment 2 spamless 2005-02-17 07:26:46 UTC
When first I was looking for info on the problem, I had found an old message
about animated cursors eating up memory, so old I assumed it had been fixed.
I see a January post on a Debian list about animated cursors eating up hundreds
of megs in a few minutes (along with a sample programme one can use to eat up
all one's memory). Gimp-Gap on my 933 MHz system takes a few minutes to work its
magic on multiple layers on multiple frames, showing the nice, rotating
hour-glass with the sands flowing in it. In Fedora Core 2 (updated to
xorg-x11-6.8.2) I renamed 

/usr/share/icons/Bluecurve/cursors/watch
  to
/usr/share/icons/Bluecurve/cursors/watch.BLOCK

so I get the default, unanimated watch cursor.

When dereferencing the new format for animated cursors, multiple images, does
memory get freed for the last image instead of the entire cursor?

Anyway, that seems to have gotten around the problem.
Comment 3 Adam Jackson 2005-12-25 18:19:25 UTC

*** This bug has been marked as a duplicate of 1043 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.