On Wed, 6 Nov 2002, David Neary wrote:

78064 Entering large dimensions in Scale Image causes fatal error Memory issue - some things use lots of memory and crash the GIMP. Enhancement, marked critical - it's a matter of pre-calculating how big the "new" image will use, and warning the user if it goes over some threshold (say 1GB?)

I think it's safe to say that if the size of the image is bigger than the size of the tile cache, it's big enough to warn about.

Rockwalrus

lutz@users.sourceforge.net (2002-11-06 at 2355.33 +0100):

In libgphoto2, someone recently implemented reading the available memory from /proc/meminfo (if available) and act according to that. The code is at

And for OSes that do not have that, like FreeBSD 4.6? It does not take into account details like disk speed or shared systems either.

GSR

On 7 Nov 2002, Lutz Müller wrote:

On Wed, 2002-11-06 at 23:05, David Neary wrote:

Looks kind of plaform-specific... how would you go about doing that for Solaris, SGI or Windows?

Alternatively, if someone hacks up a plain-C-library called libmem or similar for figuring out free memory and stuff like that on various systems, we can join the efforts in gimp and libgphoto2.

It would be a nice thing to put in glib.

Regardless, it should only be used to create a suggestion -- the tile cache size should still be determined by the user.

Rockwalrus

Hi,

Nathan Carl Summers writes:

On Wed, 6 Nov 2002, David Neary wrote:

78064 Entering large dimensions in Scale Image causes fatal error Memory issue - some things use lots of memory and crash the GIMP. Enhancement, marked critical - it's a matter of pre-calculating how big the "new" image will use, and warning the user if it goes over some threshold (say 1GB?)

I think it's safe to say that if the size of the image is bigger than the size of the tile cache, it's big enough to warn about.

remember that we already have a setting for more or less precisely that value in the prefs (max-new-image-size). I'd suggest we just use it then.

Salut, Sven

rock@gimp.org (2002-11-06 at 1430.05 -0800):

Regardless, it should only be used to create a suggestion -- the tile cache size should still be determined by the user.

Yes, cos it still does not cover shared machines, nor machines with peaks in other tasks, nor disk tweaking, nor "is the current situation at startup the normal situtation". And then you get complains, again.

GSR

On Wed, 2002-11-06 at 22:54, David Neary wrote:

Seems like a reasonable metric - but the default tile cache is 32M, and most people have upwards of 128M RAM these days. Maybe if we were to use this metric we should consider upping the default tile cache to at least 64M? If you're loading images from a camera with 3 megapixels, 32M is big enough to have 1 image open with 2 layers and no undo levels. Which seems a little harsh :)

In libgphoto2, someone recently implemented reading the available memory from /proc/meminfo (if available) and act according to that. The code is at

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gphoto/libgphoto2/libgphoto2/gphoto2-filesys.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

Look for gp_get_free_memory.

Lutz

On Wed, 2002-11-06 at 23:09, Guillermo S. Romero / Familia Romero wrote:

And for OSes that do not have that, like FreeBSD 4.6? It does not take into account details like disk speed or shared systems either.

After I wrote the email, I verified. There is currently even support for *BSD. If someone wants to add a solution for Windows or other OS, he/she is certainly very welcome :-)

Lutz

On Wed, 2002-11-06 at 23:05, David Neary wrote:

Looks kind of plaform-specific... how would you go about doing that for Solaris, SGI or Windows?

Alternatively, if someone hacks up a plain-C-library called libmem or similar for figuring out free memory and stuff like that on various systems, we can join the efforts in gimp and libgphoto2.

Lutz

David Neary wrote:

Hi all,

10498 Marching Ants die untimely deaths This has been around for yonks - anyone want to look at it?

I look at it from time to time -- I keep track of all my beasty bug children. This depends on GTK 1.2 Bug #32617 being fixed (gdk_pointer_grab() Behaves Differently for X Input Events), and apparently that is not going to be done for the 1.2 series (See Owen Taylor's Additional Comment for this item) It has been moved to resolution in the GTK 2.0 series, but I presume, being that it is still open, (moved to milestone 2.0.3) that a corresponding fix for Gimp 1.3 is also in a dependent state.

A gimp-only fix for 1.2.3 against GTK 1.2.x -- which won't see a GTK-based solution -- is conceivable: Not 'hard', but 'tedious.' It means, at the application level (in all the tool implementations that look for a release to terminate their motion behavior -- rectangles stop rubbering, for example) to anticipate a GDK_BUTTON_PRESS event, even if you didn't ask for the bugger in your request list for gdk_pointer_grab() -- this, I believe, is the essense of Mr Taylor's "two-line fix" advise.

He was speaking figuratively. Of course.

1.3 is another matter. When XInput dust settles down o'er Gimpland, #10498 may no longer be an issue. One hopes.

Be good, be well

Garry.

Hi,

David Neary writes:

After several months without one, the time has come to let ye know about the nice bugs that are still in the GIMP, and need fixing. Most of these are fairly shallow bugs against 1.2, some are meatier ones against 1.3. In any case, since the GIMP is now 3rd in the "bugs open" ranks on bugzilla.gnome.org (behind gtk+ and galeon) and have recently passed nautilus, we have some bug-fixing to do.

I just found that I clicked the wrong link on bugzilla. The page I used to look at it still shows a not-so-bad picture:

http://bugzilla.gnome.org/weekly-bug-summary.cgi

However 280 open bugs (excluding enhancement requests) are still way too many. If you want to spend some time on this stuff, the bugs that have the target milestone set to 1.2.4 are especially important to look at:

ID Sev Pri State Summary

84884 nor Nor UNCO gimp-perl man pages claims wrongs statements 83362 blo Urg NEW Incompatible licenses used in the GIMP 69085 nor Hig NEW gdyntext loses state when editing pre-existing text 3340 min Nor NEW gDynText crops text 10466 nor Nor NEW I have some pb with rotation 21028 tri Nor NEW should warn user about enormous memory consumption 26072 nor Nor NEW initial_sub_region:: error :: src->w * (src->bytes 52543 nor Nor NEW bumpmap: bumpmapping off by 1 57952 min Nor NEW no scrollable scroll bars in new picture from a sel 71478 min Nor NEW Imagemap plug-in does not draw some rectangles corr 73891 nor Nor NEW bugs in the script-fus from the Alpha to Logo secti 79754 nor Nor NEW Text tool should use gdk_fontset_load() 82465 min Nor NEW CML explorer plugin incorrect for grayscale images 82671 nor Nor NEW Flattening while thresholding causes segfault 82763 nor Nor NEW xbm plugin emits malformed xbms 84145 nor Nor NEW Narrow straight lines are imprecise 86637 nor Nor NEW Small Tiles filter: apply filter + UNDO + Repeat La 87687 tri Nor NEW ImageMap should use lowercase, not uppercase tags 89274 nor Nor NEW Gradient Editor crashes when shift dragging a segme 89801 nor Nor NEW Gimp crashes when choosing a non-integer font size 92377 nor Nor NEW missing brush-dialog.png in help .. 94979 min Nor NEW Zoom is broken for very large images 83458 tri Low NEW Suggested improvement in a translated menu 58848 nor Hig ASSI Font problem
22360 nor Nor REOP nav panner race can leave the panner active but not 52866 min Nor REOP gimp-remote is not perfect 88278 maj Nor REOP Text tool fills text with strange semi-transparent

Happy Bug-Hunting, Sven

* Sven Neumann :

83458 tri Low NEW Suggested improvement in a translated menu

(Sorry, I appear to be unable to add a comment to bugzilla. I simply can't find any "submit" button.)

I'm not a native speaker, but Google showed me a lot of sites that prefer "Sezione aurea" for "Golden mean" in italian, like

http://www.sectioaurea.com/ http://psycho81.supereva.it/bonacci.htm

Have a nice day, Nicolas

Hi,

Nicolas Kaiser writes:

* Sven Neumann :

83458 tri Low NEW Suggested improvement in a translated menu

(Sorry, I appear to be unable to add a comment to bugzilla. I simply can't find any "submit" button.)

you need to create an account and log in first.

I'm not a native speaker, but Google showed me a lot of sites that prefer "Sezione aurea" for "Golden mean" in italian, like

Thanks for your help on this. I have Cc'ed Daniel Medri since I'd prefer him to change the translation.

Salut, Sven

On Thu, Nov 07, 2002 at 11:46:14AM +0100, Sven Neumann wrote:

However 280 open bugs (excluding enhancement requests) are still way

Could somebody with sufficient priviledges allow me to edit bug reports again (account pcg@goof.com)? ;)

On Wed, 6 Nov 2002 23:55:20 +0100, "Guillermo S. Romero / Familia Romero" wrote:

rock@gimp.org (2002-11-06 at 1430.05 -0800):

Regardless, it should only be used to create a suggestion -- the tile cache size should still be determined by the user.

Yes, cos it still does not cover shared machines, nor machines with peaks in other tasks, nor disk tweaking, nor "is the current situation at startup the normal situtation". And then you get complains, again.

This has been discussed on this list several times in the past. I do not know if there was a real consensus on what the best solution is, but here are the most important points that I have in mind:

- There is no optimal way to set the tile cache size (or the value of max-new-image-size, which can be different). This depends on too many parameters (single or multi-user machine, background tasks, configuration of the swap space, etc.). So whatever we do, it will never be a perfect solution.

- Although the user should be able to change the tile cache size at any time, the value that is suggested during the initial user installation should be improved. Any guess is probably better than the current fixed value of 32 MB.

- Since the inital value needs to be computed only once during the installation, it can be guessed by any means, including running some helper programs. This is very useful for the platforms on which a normal user does not have the privileges to get this information directly from the kernel (no /proc filesystem or no permission to access it).

- The inital guess should be tuned for a single-user machine. The majority of the users are on single-user systems. Those that are on multi-user systems will usually have a system administrator who can take care of adjusting the installation script or the global gimprc in such a way that the tile cache size is set to a lower value than what would be used for a single-user system with the same amount of memory. We know that the solution will not be perfect anyway, so we have to take care of the most common case (single-user systems).

- We need to support many operating systems (Linux, Windows, MacOS X, Solaris and many others). But if we cannot have a good way to guess the appropriate value of the tile cache size for all systems, then we should at least try to get a good guess for the systems that we can support. The other systems can still use a fixed default. Again, this is a matter of taking care of the most common case.

- A good rule of thumb for setting the tile cache size seems to be: 90% of the memory available when the GIMP is running for the first time, or total amount of memory - 64 MB, whichever is the largest. So the formula would be something like: min (32 MB, max (free * 0.9, total - 64 MB)) It should probably be rounded to the closest multiple of 10 MB or 32 MB in order to get a nice value. Anyway, this is only the initial proposed value that the user can change at any time.

Just to show that it would be impossible to guess the optimal value for the tile cache size: at work, I have a home directory that is NFS-mounted on many machines. As a result, I use the same gimprc for: - my Sparc Ultra 10 (mostly single-user) with 256 MB RAM - several Sparc Ultra 1 to Ultra 60 that have the same amount of memory or more but are shared by 5 to 10 users at any time - several i686 Linux PCs with 128 to 768 MB RAM I do not want to maintain dozens of gimprc files for each machine, so I just setted for a size (200 MB) that seems to work most of the time. I adjust it sometimes when I know that I will work for some amount of time on a machine that has more memory and is not used by anybody else. Otherwise, I just keep the default because that's good enough.

But despite the fact that it would be impossible to find the optimal value for all cases, I think that it is very important to provide a better initial value than what we currently have.

-Raphaël

On Thu, Nov 07, 2002 at 06:56:33PM +0100, Raphaël Quinet wrote:

- A good rule of thumb for setting the tile cache size seems to be: 90% of the memory available when the GIMP is running for the first time, or total amount of memory - 64 MB, whichever is the largest. So the formula would be something like: min (32 MB, max (free * 0.9, total - 64 MB))

Didn't you mean something more like

max (32 MB, free * 0.9, total - 64 MB) ?

The way you wrote it no one would get more than 32MB, which probably wasn't the point.

Yeti

On Thu, 7 Nov 2002 20:59:46 +0100, David Necas (Yeti) wrote:

On Thu, Nov 07, 2002 at 06:56:33PM +0100, Raphaël Quinet wrote:

- A good rule of thumb for setting the tile cache size seems to be: 90% of the memory available when the GIMP is running for the first time, or total amount of memory - 64 MB, whichever is the largest. So the formula would be something like: min (32 MB, max (free * 0.9, total - 64 MB))

Didn't you mean something more like

max (32 MB, free * 0.9, total - 64 MB) ?

The way you wrote it no one would get more than 32MB, which probably wasn't the point.

Yes, of course. I don't know what I had been thinking when I typed that. No one should get _less_ than 32 MB as the proposed value. Your formula is what I should have typed if I had thought a bit more before sending my message.

Thanks for correcting this, -Raphaël