Re: [Gimp-developer] comparing gimp speed
On Fri, Nov 12, 2004 at 08:11:54PM +0100, Daniel Egger wrote: > On 12.11.2004, at 18:51, Manish Singh wrote: > > >>You can, but not using the typical APIs. This is pretty important > >>for database stuff > > >Whose use case is very different than GIMP's. And you do use the > >typical > >APIs, but the user does have to setup the shmfs on their own. And then > >you have to select between the shm segments yourself. > > shm is a special case. I'm talking about allocating highmem > segments. So, what is the userspace API for this? -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On Sat, Nov 13, 2004 at 12:15:22PM +0530, Laxminarayan Kamath wrote: > Manish Singh > <[EMAIL PROTECTED]> to Daniel, Sven, gimp-developer > >On Fri, Nov 12, 2004 at 06:08:17PM +0100, Daniel Egger wrote: > >... > >t's a whole bunch of contortions, and all pointless since amd64 > >hardware is competitively priced these days. > > please dont concentrate only on those who can change pcs like shirts, > concentrate on us poor people too. ;) Poor people can't afford > 4 GB of ram either, so the point is moot. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] canvas background options
-- Forwarded message -- From: Laxminarayan Kamath <[EMAIL PROTECTED]> Date: Sat, 13 Nov 2004 12:34:51 +0530 Subject: Re: [Gimp-developer] canvas background options To: David Odin <[EMAIL PROTECTED]> On Fri, 12 Nov 2004 01:02:31 +0100, David Odin <[EMAIL PROTECTED]> wrote: > Yes, this feature is important to me at least. It is important to > have a dark surrounding around a dark image and a light one around a > light image, so you can judge the contrast better. > Regards, > DindinX Hey, Then y not automatically set it to the average of the border upon loading of an image? But some images need the average of whole image, where as some need one with hoghest saturatiuon, another might need the least saturation. what we do is set one of them automatically, say the average of the border and the rest of the results be shown as a choice. and at the end of the choice, will be the cutom color chooser. Whether to do this automatically or not can be added in pref dialog -- Laxminarayan Kamath Ammembal MithraKoota, Bhoja Rao Lane, Mangalore 575003 (+91) 9845 061385 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] www.geocities.com/kamathln ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Manish Singh <[EMAIL PROTECTED]> to Daniel, Sven, gimp-developer >On Fri, Nov 12, 2004 at 06:08:17PM +0100, Daniel Egger wrote: >... >t's a whole bunch of contortions, and all pointless since amd64 >hardware is competitively priced these days. please dont concentrate only on those who can change pcs like shirts, concentrate on us poor people too. ;) -- Laxminarayan Kamath Ammembal MithraKoota, Bhoja Rao Lane, Mangalore 575003 (+91) 9845 061385 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] www.geocities.com/kamathln ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
Hi all. Alan Horkan ([EMAIL PROTECTED]) wrote: > On Fri, 12 Nov 2004, Sven Neumann wrote: > > Alan Horkan <[EMAIL PROTECTED]> writes: > > > Given my previous comments that is understandable and I think > > > discoverability is important but it doesn't make sense to have a > > > seperate menu item for every obscure feature and to me this is > > > most definately an obscure feature. > > > > It has been requested over and over again so there are certainly > > people who see a need for it. > > I never claimed some people wouldn't find it useful. You did however harp on the uselessness of this feature and advocate its removal. Despite numerous people supporting it. Just because you don't see the use of this feature that doesn't mean that it has none. > > > Perhaps I might have been less quick to complain if it had been only > > > one menu item that shows a dialog but it is not, it is a submenu > > > with several menu items and that seems a lot like clutter to me. > > > > It is a submenu, so it is only a single menu entry > > i dont follow that logic Simple: If a menu entry pops up a dialog or if a menu entry pops up a submenu is irrelevant for the menu itself. It is exactly one menu entry in the menu. It doesn't clutter less or more than a dialog. > > and thus certainly not clutter. It would have been clutter to use a > > dialog for something that can be easily done using a small submenu. > > i think a small dialog with all the options in one place would not be any > worse than the current setup It would hamper the speed to switch between different settings (menu-selection plus two clicks until you get your desired option vs. one menu-selection) and thus would cause inconvenience. There is no advantage of a dialog. At least I don't see any. Ok, the rest of the Mail are ramblings about discussions and some personal remarks, mostly (but not exclusively) targeted at Alan. I decided to post this into the public because I hope that it might help to avoid personal incidents like this in the future. > > Can we please stop this useless discussion here? > 'Useless discussion'. Sure useless. Many people did state that they like that feature. So far you're the only one who doesn't like it and wants to change it. Each party has stated its position, there is nothing to discuss unless some new facts come into the game. So far there aren't any and prolonging the thread with no arguments doesn't help. [...] > > I get the impression that you are trying very hard to find something to > > criticise. > > I'm not trying very hard to find it, finding problems is relatively easy > finding solutions and finding the time to provide feedback in way you will > actually listen to is what is time consuming. >From my point of view the most things brought up by you are details. While I like attention to the detail I don't like that these things tend to need lots of discussion. The issue here is a perfect example: Configurability of the border color. This discussion should have been over when everybody except you agreed that it is useful. Suddenly about 14 Mails pop up, 5 of these by you not understanding the point of the others. This does not help. [...] > What am trying hard to do is discuss ideas and find ways to improve things > but you seem unwilling to tolerate polite and resonable discussion, > perhaps you expect ideas to come out of nowhere fully formed or > implementations to be just right first time. Right now you are discussing a feature you don't use with people who like it. You make a big issue of something that is a non-issue for the other participants. An important part of a "polite and reasonable discussion" is to know when to stop. Sorry, you missed that point. > > Why do you have to show so much disrespect for other people's work? Ok, after battering on Alan here's one for Sven: I hate it when you pull out the "Disrespect"-bat. IMO it is a Totschlagargument and not very helpful. I don't think that exchanging arguments Gimp-related things shows disrespect on the developers. To the contrary: Caring about aspects of the GIMP is a way to show respect. And when you think that a discussion wastes your time, ignore it. Pointing at the opponent and put him in bad light is not helpful for the discussion and it does not even help to stop it. It however helps to prevent future discussions started by people who are more shy but might have brilliant ideas. Pity. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Regarding my testing on XP and ME
I've been testing on these platforms, but will be able to convert my laptop over to GNU/Linux once I can get a proper set of Mandrake discs next week - the download edition has a corrupted 2nd CD. In the meantime, I think it will be useful as more and more animators and designers are moving to XP. mC~ -- 99% of aliens prefer Earth --Eminem www.iriXx.org www.copyleftmedia.org.uk ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
Hi, Alan Horkan <[EMAIL PROTECTED]> writes: > 'Useless discussion'. > > Thanks for the encouragement, with that attitude is it any wonder more > people dont try and provide feedback and try and improve the gimp. Alan, the discussion became useless after the facts had been exchanged and several people explained you that the feature is indeed useful. That makes further discussions on this topic rather useless. Especially during times of string and UI freeze. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
Carol Spears wrote: On Fri, Nov 12, 2004 at 02:41:05AM -0800, miriam clinton (iriXx) wrote: Carol Spears wrote: On Thu, Nov 11, 2004 at 11:17:20AM -0800, miriam clinton (iriXx) wrote: just to clarify - i'm here contributing from the point of view of a professional graphic designer, considering the mainstream Adobe/Macromedia market who would have never used GIMP, and how we can 'convert them over' . This market are of the 'pick it up and use it' intuitive designers - they will reject at sight anything that requires coding, or obscure menus. have them hire someone who knows gimp for the same income. have them, at the end of the year, tally up how much each employee actually costed and compare it to their ability to produce actual results and know where all of the pieces came from. i think we will fail in selling this to people who need their employers to provide very much cushiony stuff for them and then they dont really know that much once this is all said and done. we should talk to their employers instead. who employes you? carol I'm freelance, have worked for a variety of companies in temporary contracts or purely freelance (I value my independence, and owning my own company). I would say it would take me at least double or triple time to produce a website in GIMP comparable to the industry-standard websites I produce using a combination of Fireworks/Photoshop/Dreamweaver. you took classes on how to use this software? or self-educated? carol Home-educated by a mother who did a degree in Fine Arts and taught for ~10 years. Don't worry, i'm an awful lot older than a kid now. mC~ -- 99% of aliens prefer Earth --Eminem www.iriXx.org www.copyleftmedia.org.uk ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
Carol Spears wrote: On Fri, Nov 12, 2004 at 02:41:05AM -0800, miriam clinton (iriXx) wrote: I'm freelance, have worked for a variety of companies in temporary contracts or purely freelance (I value my independence, and owning my own company). I would say it would take me at least double or triple time to produce a website in GIMP comparable to the industry-standard websites I produce using a combination of Fireworks/Photoshop/Dreamweaver. you took classes on how to use this software? or self-educated? carol Oh and yes, for the record, I picked these tools up and used them - my mother was a painter, not a graphic designer. I learnt the tools in about 30mins. Compared to the GIMP which I still havent got my head around hence my wanting to contribute - better to contribute than to whinge! mC~ -- 99% of aliens prefer Earth --Eminem www.iriXx.org www.copyleftmedia.org.uk ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
Sven Neumann wrote: Yes, the plan's to move the scripts out of the script-fu menu into the places they belong to. What's missing here though is a better menu registration functionality in Script-Fu. Kevin wanted to add a bug report about this. Actually, I was originally expecting Sven to add the bug report since he was the one who first mentioned this. :-) I have gone ahead and entered it in to bugzilla (bug #158117). I will shortly be attaching a patch file to the report which, while not yet working, provides the framework of what is needed and can be used to spark further discussions or suggestions for changes. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] fresh cvs gimp-gap and cvs gimp-2.2 crash
fresh cvs gimp-gap dosn't compile anymore with gimp-2.0. I tried to compile it with fresh cvs (today cvs) That's OK, but it definitivly crash with unknown symbols, is there anything special to do, for using it? I compiled it with --enable-gdkpixbuf-pview --disable-libmpeg3 configure options. Here, the error messages: Trying to launch storyboard: /mnt/hdc7/softs/gimp-cvs-20041112/lib/gimp/2.0/plug-ins/gap_storyboard: relocation error: /mnt/hdc7/softs/gimp-cvs-20041112/lib/gimp/2.0/plug-ins/gap_storyboard: undefined symbol: gimp_frame_new (gimp:9655): Gimp-Plug-In-WARNING **: gimp: plug_in_flush(): error: Broken pipe Trying to launch navigator: /mnt/hdc7/softs/gimp-cvs-20041112/lib/gimp/2.0/plug-ins/gap_navigator_dialog: relocation error: /mnt/hdc7/softs/gimp-cvs-20041112/lib/gimp/2.0/plug-ins/gap_navigator_dialog: undefined symbol: gimp_image_combo_box_new (gimp:9655): Gimp-Plug-In-WARNING **: gimp: plug_in_flush(): error: Broken pipe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Fri, 12 Nov 2004, Sven Neumann wrote: > Date: Fri, 12 Nov 2004 18:49:26 +0100 > From: Sven Neumann <[EMAIL PROTECTED]> > To: Alan Horkan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [Gimp-developer] canvas background options > > Hi, > > Alan Horkan <[EMAIL PROTECTED]> writes: > > > Given my previous comments that is understandable and I think > > discoverability is important but it doesn't make sense to have a seperate > > menu item for every obscure feature and to me this is most definately an > > obscure feature. > > It has been requested over and over again so there are certainly > people who see a need for it. I never claimed some people wouldn't find it useful. > > Perhaps I might have been less quick to complain if it had been only > > one menu item that shows a dialog but it is not, it is a submenu > > with several menu items and that seems a lot like clutter to me. > > It is a submenu, so it is only a single menu entry i dont follow that logic > and thus certainly not clutter. It would have been clutter to use a > dialog for something that can be easily done using a small submenu. i think a small dialog with all the options in one place would not be any worse than the current setup > Can we please stop this useless discussion here? 'Useless discussion'. Thanks for the encouragement, with that attitude is it any wonder more people dont try and provide feedback and try and improve the gimp. And you don't seem to understand why I think you are rude and abrupt. > I get the impression that you are trying very hard to find something to > criticise. I'm not trying very hard to find it, finding problems is relatively easy finding solutions and finding the time to provide feedback in way you will actually listen to is what is time consuming. There is plenty of room for improvement as the long list of bug reports in bugzilla will attest to, as the numerous FIXME in the PDB Browser and the TODO in the code. If more developers were to use other graphics software like Adobe Photoshop or Paint Shop Pro you would see there is even more ways that the gimp could be could be improved. What am trying hard to do is discuss ideas and find ways to improve things but you seem unwilling to tolerate polite and resonable discussion, perhaps you expect ideas to come out of nowhere fully formed or implementations to be just right first time. > Why do you have to show so much disrespect for other people's work? Why are you so resistant to discussion? Why are you so willing to dismiss criticisms instead of trying harder to see if things really can be improved? It is not disrespect to think that things can be improved. If I had no respect I would give up entirely and would not make any effort to use the gimp or provide feedback and try and improve it. - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On 12.11.2004, at 18:51, Manish Singh wrote: You can, but not using the typical APIs. This is pretty important for database stuff Whose use case is very different than GIMP's. And you do use the typical APIs, but the user does have to setup the shmfs on their own. And then you have to select between the shm segments yourself. shm is a special case. I'm talking about allocating highmem segments. It's a whole bunch of contortions, and all pointless since amd64 hardware is competitively priced these days. Yep. ;) I've tried GIMPing a 6 GB image on a 64-bit platform (8 GB of ram) and it handles it just fine. Duh, my Dual Opteron has only 1 GB at the moment... ;) Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] comparing gimp speed
On Fri, Nov 12, 2004 at 06:08:17PM +0100, Daniel Egger wrote: > On 12.11.2004, at 15:51, Sven Neumann wrote: > > >That allows you to stuff more RAM into your box but you can still only > >give up to 4GB to a single process simply because you cannot handle > >more than 4GB in a 32bit address space. > > You can, but not using the typical APIs. This is pretty important > for database stuff Whose use case is very different than GIMP's. And you do use the typical APIs, but the user does have to setup the shmfs on their own. And then you have to select between the shm segments yourself. It's a whole bunch of contortions, and all pointless since amd64 hardware is competitively priced these days. I've tried GIMPing a 6 GB image on a 64-bit platform (8 GB of ram) and it handles it just fine. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
Hi, Alan Horkan <[EMAIL PROTECTED]> writes: > Given my previous comments that is understandable and I think > discoverability is important but it doesn't make sense to have a seperate > menu item for every obscure feature and to me this is most definately an > obscure feature. It has been requested over and over again so there are certainly people who see a need for it. > Perhaps I might have been less quick to complain if it had been only > one menu item that shows a dialog but it is not, it is a submenu > with several menu items and that seems a lot like clutter to me. It is a submenu, so it is only a single menu entry and thus certainly not clutter. It would have been clutter to use a dialog for something that can be easily done using a small submenu. Can we please stop this useless discussion here? I get the impression that you are trying very hard to find something to criticise. Why do you have to show so much disrespect for other people's work? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On Fri, 12 Nov 2004 11:34:35 +0100, Daniel Egger <[EMAIL PROTECTED]> wrote: > It would be really cool if the pixel data addressing was pluggable so > one could easily write a different storage backend. On top of my head > there would be several schemes I'd like to try: > > - A simple linear memory segment with COW for new layers > - dito but with RLE compression (and thus more complex addressing) > - Line based addressing with COW and aliasing for duplicate lines, >with LUT for each line > - Planar memory segments (Shoot now! ;)) > > I don't know what GEGL will buy us exactly because we certainly > need a change from "store those 32bit RGBA values" to something > more variable but IIRC GEGL is only about pixel composition, not > storage. GEGL is about image compositing, not pixel compositing, thus it has to deal with efficient memory representations as well. In my view of how things will be after a full integration, gimp uses GEGL for all it's image processing needs, even the paint tools will most likely be reimplemented to use GEGL. The largest problem with making the image representation pluggable is that it either complicates op (short for image operation, plug-ins in GEGL) development or adds overhead due to additional copying of values needed to provide a simple interface. Layers (or their equivalents after GEGL integration) can theoretically be unbounded surfaces instead of square,. there are various ways to such sparse allocation of images, and IIRC the tile based caching system Dan implemented in gegl/gegl/image would allow this. After integration of GEGL various other speedups can be achived, by for instance caching static portions of the compositing graph, other optimizations and rearrangements are also possible on the graph level. /pippin -- Software patents hinder progress | http://swpat.ffii.org/ Web : http://pippin.gimp.org/ <- that's where my GEGL like playground is hidden ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On 12.11.2004, at 15:51, Sven Neumann wrote: That allows you to stuff more RAM into your box but you can still only give up to 4GB to a single process simply because you cannot handle more than 4GB in a 32bit address space. You can, but not using the typical APIs. This is pretty important for database stuff Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] canvas background options
On Fri, 12 Nov 2004, Jakub Friedl (lists) wrote: > Date: Fri, 12 Nov 2004 16:57:51 +0100 > From: "Jakub Friedl (lists)" <[EMAIL PROTECTED]> > To: Alan Horkan <[EMAIL PROTECTED]>, > GDev <[EMAIL PROTECTED]> > Subject: Re: [Gimp-developer] canvas background options > > > I'm surprised that enough users would be changing the setting often enough > > to want to be able to set it on a once off per window basis, I would have > > though that a single global preference would to override the toolkit > > default would have been enough > > oh please no. or is the gimp supposed to be used only by beginners and > not by advanced users? That line of reasoning can be used to justify adding a whole lot of crud to the gimp that only really benefits the advanced users. if anything recent development has been removing little used plugins to reduce the maintainance burden. the gimp is the de facto standard for image editing on Linux, FreeBSD, Solaris, and I'm sure a few others. I there hardly any other piece of graphics software as likely to be available as the gimp. As such is extremely important to cater to ordinary users. I don't want to make the gimp into something that "advanced users" cannot use quickly and efficiently either, but an uncluttered streamlined user interface should be of benefit to everyone. I wish you would have resited the urge to overreact, all this is just dicussion and although I would prefer not to have the Canvas Padding feature I do not think my suggestions have yet been convincing enough. > a month ago i was making three images to be placed on a wall, each of > them on different one, painted with different colour. i was painting > them at the same time (they were a series) > and i enjoyed the possibilty to see them all against the proper colour. I'm still convinced it is a minority feature and although it may be useful I'm not convinced it is useful enough for most users to deserve such prominant location in the menus. Gimp 2.2 seems to be largely decided, and it is unlikely that my suggestion would be taken on board until after 2.2 has been released. > BTW: if you feel that the gimp should be simplified as possible for > beginners, I believe it should be simplified for everyone, most usability improvements are optimisation of a different kind and just as accessibility benifts more than just the disabled so too should good usability benfit everyone. I'm not arrogant enough to claim I'm an expert, but I thought I should be able to discuss the change before 2.2 and if I didn't do it now I'd probably be berated for not having mentioned it sooner. > wouldnt be possible to keep advanced features visible for advanced users > but not for beginners? but not remove them completelly? single option in > preferences (or in gimprc file) which would enable more advanced > features which some consider as interface clutter but others may need > them? Did you use Nautilus when it had a Normal mode and an Advanced mode? It was a disaster because most users wanted one or two of the supposedly "Advanced features" which meant turing on a whole lot of other advanced features. It is better to think of the task and the results you are trying to achieve and see if there is a way to stream line the process. I do not doubt that it is useful for you to have a way to easily compare your image against various backgrounds. What I am asking is if the current implementation is really the best way to provide that feature? You have made it clear that you want to be able to set a different background colour for each image. Do you set different colours for different views of the same image? If so might it not be beter even better to reorganise this functionality in a way that allowed you to more quickly preview an image with various different background rather than having to choose a different back colour each time you wanted to make your comparisions. If you describe in more detail how exactly you go about your work I might be able to refine my suggestions. I'm trying to make things easier for _everyone_ including you :) Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
> I'm surprised that enough users would be changing the setting often enough > to want to be able to set it on a once off per window basis, I would have > though that a single global preference would to override the toolkit > default would have been enough oh please no. or is the gimp supposed to be used only by beginners and not by advanced users? if you do some more serious work you need often to change the colour of the surrounding area. and you need it to do by per image basis. if i edit images where colour is really important (and this will be even more useful when gimp will be able to handle colour management) i always set my gui theme to colours of neutral grey so there is no colour distraction + i change this setting in the gimp often to simulate different colour enviroments. the feature is invaluable for an advanced user. a month ago i was making three images to be placed on a wall, each of them on different one, painted with different colour. i was painting them at the same time (they were a series) and i enjoyed the possibilty to see them all against the proper colour. BTW: if you feel that the gimp should be simplified as possible for beginners, wouldnt be possible to keep advanced features visible for advanced users but not for beginners? but not remove them completelly? single option in preferences (or in gimprc file) which would enable more advanced features which some consider as interface clutter but others may need them? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Fri, 12 Nov 2004, Sven Neumann wrote: > Date: Fri, 12 Nov 2004 15:39:58 +0100 > From: Sven Neumann <[EMAIL PROTECTED]> > To: Alan Horkan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [Gimp-developer] canvas background options > > Hi, > > Alan Horkan <[EMAIL PROTECTED]> writes: > > > I can understand how that would require you to change it regularly > > and why you might want a menu item for it. How did you like how the > > feature was presented in 2.0 or were you unaware of it until it was > > given a prominant menu item? > > Hiding useful functionality in some obscure button with a right-click > popup menu in the image corner is not really good user interface > design and I am very much surprised that you don't consider this > change an improvement. Given my previous comments that is understandable and I think discoverability is important but it doesn't make sense to have a seperate menu item for every obscure feature and to me this is most definately an obscure feature. (most of the time I shrink wrap my images and dont even see the canvas padding, if I wanted to regularly preview images against a black background I would probably configure the Fullscreen mode for that purpose) Perhaps I might have been less quick to complain if it had been only one menu item that shows a dialog but it is not, it is a submenu with several menu items and that seems a lot like clutter to me. > We also needed that space in the upper right corner for a more useful > and less obscure feature that is also being offered in other > applications: linking the image zoom ratio to the window size. That does seem like a good idea of itself but I dont think it makes the menu items for Canvas Padding idea any better than a workaround. I'm surprised that enough users would be changing the setting often enough to want to be able to set it on a once off per window basis, I would have though that a single global preference would to override the toolkit default would have been enough (which is as far as I can go towards offering an alternative implementation). Sincerely Alan Horkan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
On Fri, Nov 12, 2004 at 02:41:05AM -0800, miriam clinton (iriXx) wrote: > Carol Spears wrote: > > >On Thu, Nov 11, 2004 at 11:17:20AM -0800, miriam clinton (iriXx) wrote: > > > > > >>just to clarify - i'm here contributing from the point of view of a > >>professional graphic designer, considering the mainstream > >>Adobe/Macromedia market who would have never used GIMP, and how we can > >>'convert them over' . This market are of > >>the 'pick it up and use it' intuitive designers - they will reject at > >>sight anything that requires coding, or obscure menus. > >> > >> > >> > >have them hire someone who knows gimp for the same income. have them, > >at the end of the year, tally up how much each employee actually costed > >and compare it to their ability to produce actual results and know where > >all of the pieces came from. > > > >i think we will fail in selling this to people who need their employers > >to provide very much cushiony stuff for them and then they dont really > >know that much once this is all said and done. > > > >we should talk to their employers instead. > > > >who employes you? > > > >carol > > > > > > I'm freelance, have worked for a variety of companies in temporary > contracts or purely freelance (I value my independence, and owning my > own company). > > I would say it would take me at least double or triple time to produce a > website in GIMP comparable to the industry-standard websites I produce > using a combination of Fireworks/Photoshop/Dreamweaver. > you took classes on how to use this software? or self-educated? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: >> Of course there's also a physical limit and you would need a 64bit >> CPU in order to use more than 4GB. > > Not necessarily, there some CPU extensions for x86 CPUs which > allow larger memory sizes by using extra large pages (more > overhead) or providing additional bits for the paging tables > which allow for a maximum of 64 GByte on reasonably equipped > motherboards. That allows you to stuff more RAM into your box but you can still only give up to 4GB to a single process simply because you cannot handle more than 4GB in a 32bit address space. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: High-performance gimping
Hi, Dov Kruger <[EMAIL PROTECTED]> writes: > I suggest modifying the documentation to read something like: > > Increasing tile memory cache will continue to yield benefits until you > totally saturate physical memory. If you can afford to give nearly all > your physical memory to gimp while you are running it, and you need to > process large images, then do so. Could you open a bug report that reminds us to do such a change as soon as 2.2 is out and the string freeze is over? And perhaps open a separate bug report against the Help component asking the help authors to improve the docs as well? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
Hi, Alan Horkan <[EMAIL PROTECTED]> writes: > I can understand how that would require you to change it regularly > and why you might want a menu item for it. How did you like how the > feature was presented in 2.0 or were you unaware of it until it was > given a prominant menu item? Hiding useful functionality in some obscure button with a right-click popup menu in the image corner is not really good user interface design and I am very much surprised that you don't consider this change an improvement. We also needed that space in the upper right corner for a more useful and less obscure feature that is also being offered in other applications: linking the image zoom ratio to the window size. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] memory usage
Hi, "Adam D. Moss" <[EMAIL PROTECTED]> writes: > But it still seems like the elegant way to do this (erk, but it > probably did rely on the projection being able to assume the > same depth as the image). At the moment the projection is always RGBA but the code to do grayscale and indexed projections hasn't been removed. I don't know if it would still work since it hasn't been used for years but it should still be there. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Fri, Nov 12, 2004 at 12:48:02PM +, Alan Horkan wrote: > > On Fri, 12 Nov 2004, David Odin wrote: > > > Date: Fri, 12 Nov 2004 01:02:31 +0100 > > From: David Odin <[EMAIL PROTECTED]> > > To: Alan Horkan <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: Re: [Gimp-developer] canvas background options > > > > On Thu, Nov 11, 2004 at 11:06:21PM +, Alan Horkan wrote: > > > > > > I noticed the Canvas background colour options under the Image menu in the > > > gimp 2.2. > > > > > > In gimp 2.0 this option was fairly discrete and was available on the top > > > right just above the scrollbar which seemed fair enough even if it was > > > not something I would ever change (except perhaps by changing my desktop > > > theme). > > > > > > Is this feature really important to some users, so much so that it needs > > > menu items? I am suggesting it would be better to put this in the > > > preferences if at all rather than cluttering the menus. > > > > > Yes, this feature is important to me at least. It is important to > > have a dark surrounding around a dark image and a light one around a > > light image, so you can judge the contrast better. > > I can understand how that would require you to change it regularly and why > you might want a menu item for it. > How did you like how the feature was presented in 2.0 or were you unaware > of it until it was given a prominant menu item? > I tend to prefer the gimp-2.0 way since it is quicker to use. I don't remember why it has been put to the menu. A "prominant menu item" as it is now also let the user to tear it off and have it handy. So my preference (have it on the upper right corner window) is only a matter of taste I guess. Regards, DindinX -- [EMAIL PROTECTED] Do jellyfish get gas from eating jellybeans? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: High-performance gimping
Thanks to all who responded with useful comments. It isn't entirely clear from the comments when gimp starts up, but the tiling cache should indeed be almost as large as physical memory, allowing some for other uses (such as the OS). Increasing to 1500Mb on a 2G system was a huge improvement. I have not sought to tune that number, not doing enough of these to make that worthwhile. The undo suggestion of Alastair Robinson is also probably very good for continued manipulation. As I think the original posting indicated, allowing virtual memory to do the work, is for whatever reason not the answer. I suggest modifying the documentation to read something like: Increasing tile memory cache will continue to yield benefits until you totally saturate physical memory. If you can afford to give nearly all your physical memory to gimp while you are running it, and you need to process large images, then do so. thanks, Dov > If the OS has better virtual memory than what available to gimp, >then you would want to use that one. In Linux, I think in most >cases, you would want to use the (often in multiple disks) swap >partitions/files available to the OS. Evidently not, as in my first post. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On 12.11.2004, at 13:12, Sven Neumann wrote: The operating system imposes a limit on the maximum amount of memory that can be allocated by a process. IIRC the limit is 3GB on Linux. Typically the splitting point (user/kernel and peripheral memory) would be 2:2, but there is a way to easily get 3:1 (if you do not need the additional GByte for say a GPU framebuffer); hardcore users may also want to try a 3.5:0.5 splitting but IIRC that will only be possible with some nasty patch and have several limitations. Of course there's also a physical limit and you would need a 64bit CPU in order to use more than 4GB. Not necessarily, there some CPU extensions for x86 CPUs which allow larger memory sizes by using extra large pages (more overhead) or providing additional bits for the paging tables which allow for a maximum of 64 GByte on reasonably equipped motherboards. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] comparing gimp speed
Date: Fri, 12 Nov 2004 14:23:49 +0100 From: Tino Schwarze <[EMAIL PROTECTED]> Hi, On Fri, Nov 12, 2004 at 01:12:33PM +0100, Sven Neumann wrote: > > [1] Working ain't gonna be fun - I once had an A1 poster at 300 dpi on > > an 6 GB machine and GIMP's swap grow as large as another 6 GB since GIMP > > didn't seem to be able to use more than 2 or 3 GB of memory altogether. > > (Is there a known limitation regarding maximum usable memory?) > > The operating system imposes a limit on the maximum amount of memory > that can be allocated by a process. IIRC the limit is 3GB on Linux. Ah, then it was probably this limit. 32-bit Linux, that is. Get an Opteron/Athlon 64 or other 64-bit processor and you don't have this kind of a limit (it's much, much higther). > Of course there's also a physical limit and you would need a 64bit CPU > in order to use more than 4GB. There's PAE36 or High memory[1]. You only need a kernel compiled with 4GB or 64GB support (the machine was Xeon with 6 GB). That has nothing to do with process size limit. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Hi, On Fri, Nov 12, 2004 at 01:12:33PM +0100, Sven Neumann wrote: > > [1] Working ain't gonna be fun - I once had an A1 poster at 300 dpi on > > an 6 GB machine and GIMP's swap grow as large as another 6 GB since GIMP > > didn't seem to be able to use more than 2 or 3 GB of memory altogether. > > (Is there a known limitation regarding maximum usable memory?) > > The operating system imposes a limit on the maximum amount of memory > that can be allocated by a process. IIRC the limit is 3GB on Linux. Ah, then it was probably this limit. > Of course there's also a physical limit and you would need a 64bit CPU > in order to use more than 4GB. There's PAE36 or High memory[1]. You only need a kernel compiled with 4GB or 64GB support (the machine was Xeon with 6 GB). Bye, Tino. [1] Works like EMS from old DOS times. :-| ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Hi, Daniel Egger wrote: > It would be really cool if the pixel data addressing was pluggable so > one could easily write a different storage backend. On top of my head > there would be several schemes I'd like to try: > - A simple linear memory segment with COW for new layers > - dito but with RLE compression (and thus more complex addressing) > - Line based addressing with COW and aliasing for duplicate lines, > with LUT for each line > - Planar memory segments (Shoot now! ;)) > > I don't know what GEGL will buy us exactly because we certainly > need a change from "store those 32bit RGBA values" to something > more variable but IIRC GEGL is only about pixel composition, not > storage. There are better people to talk about this than me (Dan, are you reading?) but part of gegl is about data representation, and that includes its representation in memory (tiles, scanlines, whatever). I know that Dan Rogers was working on a GeglTiledImage structure at one stage, which had its own tile manager. Given the object structure, perhaps some of the alternate schemes you describe could be accomplished by inheriting from GeglImage and implementing the extra bits. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Fri, 12 Nov 2004, David Odin wrote: > Date: Fri, 12 Nov 2004 01:02:31 +0100 > From: David Odin <[EMAIL PROTECTED]> > To: Alan Horkan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [Gimp-developer] canvas background options > > On Thu, Nov 11, 2004 at 11:06:21PM +, Alan Horkan wrote: > > > > I noticed the Canvas background colour options under the Image menu in the > > gimp 2.2. > > > > In gimp 2.0 this option was fairly discrete and was available on the top > > right just above the scrollbar which seemed fair enough even if it was > > not something I would ever change (except perhaps by changing my desktop > > theme). > > > > Is this feature really important to some users, so much so that it needs > > menu items? I am suggesting it would be better to put this in the > > preferences if at all rather than cluttering the menus. > > > Yes, this feature is important to me at least. It is important to > have a dark surrounding around a dark image and a light one around a > light image, so you can judge the contrast better. I can understand how that would require you to change it regularly and why you might want a menu item for it. How did you like how the feature was presented in 2.0 or were you unaware of it until it was given a prominant menu item? - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Hi, Tino Schwarze <[EMAIL PROTECTED]> writes: > [1] Working ain't gonna be fun - I once had an A1 poster at 300 dpi on > an 6 GB machine and GIMP's swap grow as large as another 6 GB since GIMP > didn't seem to be able to use more than 2 or 3 GB of memory altogether. > (Is there a known limitation regarding maximum usable memory?) The operating system imposes a limit on the maximum amount of memory that can be allocated by a process. IIRC the limit is 3GB on Linux. Of course there's also a physical limit and you would need a 64bit CPU in order to use more than 4GB. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] memory usage [was: comparing gimp speed]
Sven Neumann wrote: You will however notice that GIMP instead needs 8 bytes per pixel. In addition to the 3 bpp for the RGB layer it allocates a projection the size of the image. This projection holds the result of compositing the layer stack. It is always allocated 4 bpp. Additionally a selection mask is allocated which adds another byte per pixel. (As an aside, once upon a time, we did have such a thing as greyscale projections.) So what could be done to improve this? We could for example try to get around the need for a projection for the case where people are working with a single layer only. Instead of displaying from the projection, we could display directly from the layer. I think we used to do this, too. At least, I struggled for a long time making the projection tiles be initialised to a lazy copy-on-write reference to the bottom layer (IIRC the tile hinting system would also preserve these cheap refs even when there were multiple layers where the upper layers were largely transparent). There were some annoying corner cases (duplicating a zoomed-in image) which I now don't remember if we ever got right. :( But it still seems like the elegant way to do this (erk, but it probably did rely on the projection being able to assume the same depth as the image). It might also help to allocate the selection lazily. That is to not allocate the tiles at all until the selection mask is altered. This might actually happen already, I am not sure about it. Not sure. Might be able to do this elegantly (elegance again being in the eye of the beholder) by initialising all of the selection tiles to a COW of the same 'blank' tile (and doing the same in the 'clear selection' operation, etc). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On Fri, Nov 12, 2004 at 04:49:03PM +0530, Laxminarayan Kamath wrote: > What about making gimp do a benchmaking on the machine and then let it > automatically decide what method 2 use for that swapping/ tiling > stuff.. < Hey, now dont beat me. I confess i actually know none of the > stuff> Unfortunately, this is not practical because: a) you don't want to beat the machine for several minutes just to figure such things out b) you don't know the usual workload of the machine. It may be a single user machine (BTW tomorrow it'll get a memory upgrade) or a multi user machine where currently no one is working or maybe 10 people are computing like hell c) I/O intensive stuff may be running (user is burning CD, updatedb from locate is running, virus scanner runs or the machine is busy copying a DVD full of video or imagery) d) Linux kernel is upgraded tomorrow which has got a totally new VM (which is not very unlikely ;-> ) ... add you own Bye, Tino. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
What about making gimp do a benchmaking on the machine and then let it automatically decide what method 2 use for that swapping/ tiling stuff.. < Hey, now dont beat me. I confess i actually know none of the stuff> -- Laxminarayan Kamath Ammembal MithraKoota, Bhoja Rao Lane, Mangalore 575003 (+91) 9845 061385 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] www.geocities.com/kamathln ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] memory usage [was: comparing gimp speed]
Hi, there are probably a few things we could try to do to reduce memory usage when working with large images. The main problem here is that if you open an RGB image (no alpha channel) with say 1000 x 1000 pixels, you would expect GIMP to use 1000 * 1000 * 3 bytes to store the image data. You will however notice that GIMP instead needs 8 bytes per pixel. In addition to the 3 bpp for the RGB layer it allocates a projection the size of the image. This projection holds the result of compositing the layer stack. It is always allocated 4 bpp. Additionally a selection mask is allocated which adds another byte per pixel. So what could be done to improve this? We could for example try to get around the need for a projection for the case where people are working with a single layer only. Instead of displaying from the projection, we could display directly from the layer. Of course we would still have to allocate the projection as soon as you start to work with layers or floating selections but at least we could reduce the memory footprint that is needed to open the image and have a first look at it. A more elegant way to implement this is is to share the projection tiles with layer tiles whenever possible (i.e. when the topmost layer is in Normal mode and the tile is completely opaque). It might also help to allocate the selection lazily. That is to not allocate the tiles at all until the selection mask is altered. This might actually happen already, I am not sure about it. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
Sven Neumann wrote: Hi, "miriam clinton (iriXx)" <[EMAIL PROTECTED]> writes: Script-Fu is totally incomprehensible to graphic designers Actually you are not supposed to recognize that it's a script-fu. How to achieve that is what we are discussing at the moment. Sven Brilliant! I was just saying that the very name Script-Fu is cute, but doesnt really say to a designer 'look for cool fx here'... or even your standard effects (drop shadow is an /essential/ and must not be obscured). Just to explain - I dropped out of this list for a while after an argument over my website and w3c issues. As i said, I've promised not to bring up the issue again as long as noone else does ;). But that explains why I havent been following for the last week or so. Best, mC~ -- 99% of aliens prefer Earth --Eminem www.iriXx.org www.copyleftmedia.org.uk ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
Hmm, will give it a try. Again, not easy to find - designers also work under a great deal of pressure to get stuff done fast, and a tool where selections appear obscured will not encourage them so easily. Cinepaint, though, has had a great deal of success. I'm going to be interested to compile it (again a problem for designers) and have a taste. The name Script-Fu is cute, but /very/ programmer-speak... a designer has no idea what it means, or that it means 'look for effects here' mC~ Popolon wrote: That was about the GUI menu... In menu bar, there is a Script-Fu menu with Selection sub-menu containing the To Brush item. Shorter it's: Script-Fu->Selection->To Brush miriam clinton (iriXx) wrote: okay... since i'm in the Hotel California where you can check in but never check out from a graphic designer's point of view this is a nightmare... most of them wouldnt know how to use the Bash shell, or only the basics, let alone how to do this. Is it possible to design a GUI implementation of the same script? The Select-To sounds good but its gotta be a short menu - preferably within the Brush palette itself... thats where we'd think to look for it... Script-Fu is totally incomprehensible to graphic designers Just my 2c from the graphics corner... mC~ (who has promised not to write on w3c issues ever again, as long as noone else does ;P ) Popolon wrote: Actually in Select menu there is two items "To Path" and "Save To Channel". I searched long time how to convert selection to brush, I think that the only way was to save brush to a file, move the file to ~/.gimp-xx/brush folder and restart gimp. This week in a newsgroup, another guy searched didn't find how to convert a selection to a pattern. For him the only way was to save selection to move the file to ~/gimp-xx/pattern folder and restart gimp :(. A day, don't know exactly for why, By wandering in gimp menus, I find the miraculous: Script-Fu->Selection->To Brush/Image/Pattern I believe (perhaps wrong), that the human logic is to use the same tool to do nearly the same thing. The menu Select could have an organisation for these conversions as: Select->To...->[Brush/Channel/Image/Path/Pattern/...] to avoid a to long Select menu. and a 'Selection To Brush/Pattern' button could be in brush/Pattern windows, as there is 'Selection to Path' button in Path window. This could improve speed of The Gimp apprenticeship and workflow for some tasks. Regards Popolon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- 99% of aliens prefer Earth --Eminem www.iriXx.org www.copyleftmedia.org.uk ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
Hi, Alan Horkan <[EMAIL PROTECTED]> writes: > Is this feature really important to some users, so much so that it > needs menu items? I am suggesting it would be better to put this in > the preferences if at all rather than cluttering the menus. It is indeed important to be able to change this for individual displays. Of course there's also a way to configure the defaults in the preferences dialog. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Hi there, On Fri, Nov 12, 2004 at 02:13:46AM +0200, Steve Stavropoulos wrote: > > The most important thing to do is balance your tile cache setting, as > > you've already found. You want it large enough that GIMP doesn't have > > to use its own virtual memory, but not so large that the OS has to use > > virtual memory to accommodate it. On a 2GB machine, I'd set to about > > 1.5GB, assuming GIMP has pretty much free reign over the machine. > If the OS has better virtual memory than what available to gimp, then > you would want to use that one. In Linux, I think in most cases, you > would want to use the (often in multiple disks) swap partitions/files > available to the OS. You don't want to use virtual memory if you don't have to. So give as much memory to GIMP as possible without making the OS swap. > If you want to keep the system friendly to other apps as well, you > might consider a smaller than the available memory tile cache > setting... > > PS. SOT: many people have more than one disk on their system. In that > case they should consider these example fstab entries: > /dev/hdf1 swapswapdefaults,pri=0 0 0 > /dev/hdg5 swapswapdefaults,pri=0 0 0 > /stuff/swap swapswapdefaults,loop,pri=0 0 > 0 > (you might spell it as: "raid0 swap with three disks") It has always been pointed out that the access patterns of GIMP are very specific to image operations - the tile cache is there because it gives a significant advantage compared to the OS's virtual memory. Besides, you get the advantage that the tile cache can be a lot larger than usable physical memory[1]. BTW: You can easily try OS-only virtual memory by setting the tile cache very large (like all of your swap), then compare whether it performs better than limiting the tile cache to physical memory (minus some amount for OS, Window environment and GIMP itself). Bye, Tino. [1] Working ain't gonna be fun - I once had an A1 poster at 300 dpi on an 6 GB machine and GIMP's swap grow as large as another 6 GB since GIMP didn't seem to be able to use more than 2 or 3 GB of memory altogether. (Is there a known limitation regarding maximum usable memory?) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
Jakub Friedl (lists) wrote: please use Win 98 or XP if you have to use Windows, but not ME. It is the worst system from Microsoft available. I'm testing on both Win ME (forced to by a proprietary laptop) and XP. XP has a nice widget set. But a designer - a vanilla designer, not a programmer-designer like yourself, wouldnt have a clue what a widget is mC~ -- 99% of aliens prefer Earth --Eminem www.iriXx.org www.copyleftmedia.org.uk ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On 12.11.2004, at 01:13, Steve Stavropoulos wrote: If the OS has better virtual memory than what available to gimp, then you would want to use that one. In Linux, I think in most cases, you would want to use the (often in multiple disks) swap partitions/files available to the OS. GIMP does tile swapping by hand, so if you hit the limits you'll get a lot of files in the .gimp directory of your homedirectory or whatever you set the swap area to. I once tried to modify this to have the tile cache use mmap memory with file backing to truly let the OS decide where to put the tiles (memory or file), however this was a really sad performer so I ditched the code. I wonder whether photoshop works with tiles at all or simply uses a linear memory segment and let the OS do the rest. It would be really cool if the pixel data addressing was pluggable so one could easily write a different storage backend. On top of my head there would be several schemes I'd like to try: - A simple linear memory segment with COW for new layers - dito but with RLE compression (and thus more complex addressing) - Line based addressing with COW and aliasing for duplicate lines, with LUT for each line - Planar memory segments (Shoot now! ;)) I don't know what GEGL will buy us exactly because we certainly need a change from "store those 32bit RGBA values" to something more variable but IIRC GEGL is only about pixel composition, not storage. Servus, Daniel PGP.sig Description: This is a digitally signed message part
