Re: [Gimp-developer] GIMP performance

2009-04-02 Thread Rob Antonishen
On Thu, Apr 2, 2009 at 3:39 AM, David Gowers wrote:
 Hello Andrea,

 On Thu, Apr 2, 2009 at 5:16 PM, Andrea Olivotto
 Another request for you: I'm a firmware programmer, and I know C programming
 quite well, and some time ago I tried to compile GIMP in Windows enviroment,
 but I can't find a complete tutorial, relative to 2.6 tree (and now 2.7).


 Is
 http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows


I just compiled under XP following the wiki last weekend and  had to
modify two lines of the
http://wiki.gimp.org/gimp/CompileGimpAtWindowsShellScript file in
order to get it working.

After a quick email with Carl who suggested:

 A better option is maybe try to modify a line both within the
 download_and_zextract function and the download and tbz2extract
 function, from this:

 wget $WGETFLAGS $PACK_LOCATION/$PACKAGE.zip 21 | grep -v -i 
 ^sys\(tem_\)\?wgetrc;

 to this

 wget $WGETFLAGS $PACK_LOCATION/$PACKAGE.zip

-Rob A
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP performance

2009-04-01 Thread David Gowers
Hello Andrea!

On Thu, Apr 2, 2009 at 1:57 AM, Andrea Olivotto
and...@andreaolivotto.com wrote:
 Hi all,

 I'm a photo amateur, and I do like gimp. I posted some time ago some
 hints to make gimp more useful for photo retouch, and some have been
 done in 2.6.

 At this time, gimp seems to me that need speed. It is far away from
 Photoshop and other commercial softwares, and things are getting worse
 using GEGL (as I tried in 2.7 development program): I checked in Windows
 and in Ubuntu 8.10, AMD 3000+/64 plus 1GB RAM.
GEGL *is* what we are doing to increase performance. It's true that
currently GEGL is much slower, however, the previous GIMP architecture
was incapable of the optimizations and storage strategies required for
particularly large images, and also was very limited (no support for
higher bit depths, no automatic colorspace conversion so that any
image can be used as input to any operation).
Chances are that GEGL is already better at managing graphics than GIMP ever was.
It still needs quite a bit of work, but in my understanding, the
slowness is caused by the way GEGL is being used by GIMP. It could be
a lot better; and by the time GEGL is really well integrated, we could
reasonably expect far better responsiveness and comparable real speed,
with the possibility of vast speed increases for certain kinds of
filter/plugin.


 When I use curves, preview is redrawed very slowly, I can see the
 blocks under updating.
Things like Curves could certainly be done much quicker. A lot of
conversion goes on during the calculation; but really, for applying to
8bit and 16-bit pictures, a lookup table should be all that is needed,
with only a very little amount of conversion work that happens as soon
as the curve is adjusted. This means that currently, GIMP is making
GEGL do much more work than it needs to really do. These issues will
be settled as GIMP developers learn more about using GEGL, GEGL
matures, and as GEGL becomes better integrated in GIMP.


 I know that GIMP is open source, and developers don't want to compete
 with Photoshop (or Photoshop Express, or Paint Shop PRO, ...), but this
 is the real world in photo retouching. I just want to be honest, end to
 emphasize this issue.

I hope I've addressed your concerns.

David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer