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
[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] 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
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] 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
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
[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] 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] 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] 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] 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' gets off evangelistic soapbox/. 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] 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] 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, 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] 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] 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] 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] 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...
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' gets off evangelistic soapbox/. 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
[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 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
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
[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
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
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
