Re: [Gimp-developer] The Occasional Bug List
David Neary wrote: Garry R. Osgood wrote: snip comment I'd suggest adding this comment to bugzilla, and closing the bug as NOTGIMP or NOTGNOME, or whatever bugzilla status corresponds to SEP (someone else's problem). Apologies - this comment (with lots more information) is already attached to the bug report. I just thought of something else - can we close this bug as a duplicate of the GTK+ bug? Cheers, Dave. -- David Neary, Marseille, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Occasional Bug List
Hi, David Neary [EMAIL PROTECTED] 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: IDSev 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Occasional Bug List
On Thu, Nov 07, 2002 at 11:46:14AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: However 280 open bugs (excluding enhancement requests) are still way Could somebody with sufficient priviledges allow me to edit bug reports again (account [EMAIL PROTECTED])? ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tile cache size (was Re: The Occasional BugList)
On Wed, 6 Nov 2002 23:55:20 +0100, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tile cache size (was Re: The Occasional BugList)
On Thu, Nov 07, 2002 at 06:56:33PM +0100, Raphal 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: GIMP 1.3.10
Hi, if you have some spare CPU cycles and bandwidth, you probably want to go to ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.10/ and download the latest development release of The GIMP. Some of the mirrors should already have it, so perhaps you try one next to you: http://www.gimp.org/download.html Here's the obligatory list of changes since the latest release: - Text tool can load text files now [Sven] - Some unfinished work on the imagemap tools and related widgets [Sven] - Undeprecated ink tool [Bolsh, Sven] - Slightly tweaked the look and feel of the toolbox [Mitch, Sven] - Ported module loading to GTypeModule [Mitch] - Resurrected the water color selector [Mitch] - Reworked module browser [Mitch] - Moved generic datafile loading to LibGimpBase [Mitch] - Added GimpColorScale widget [Mitch, Sven] - Added GimpPickButton widget [Mitch] - Added a color selector dock [Mitch] - Added new layer modes (Softlight, Grain Extract, Grain Merge) [UnNamed] - Included Gimp-Python with the tarball (try --enable-python) - Lots of bug fixes Other contributors: Maurits Rijk, Michael Niedermayer, Garry R. Osgood, David Necas, Toby Smith, Raphael Quinet, Dave Neary, Jim Meier It's nice to note that we have an increasing number of contributors. Please keep up the good work, we need your help! Thanks to James Henstridge and Yosh this release includes Python bindings for The GIMP. If you have Python 2.2 and PyGTK you might want to pass --enable-python to configure and give it a try. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
