On 2002-12-03 at 1839.16 -0800, Jonathan Cohen typed this:
> Hi,
> That said, the software engineer in me is slightly saddened by the fact
> that we are duplicating (some) efforts from the gimp programmers.  I'm
> sure most of what is on our todo list is on the gimp's todo list as well
> (or has already been done).  However, some of things on our list
> definately are *not* the same.  For example, we are eager to remove the
> color & index modes we do not need for performance and cleanliness
> reasons.  We are seriously considering ripping out all modes except for
> 32-bit floating point. This would drastically simplify the internal
> rendering engine and allow us to optimize it significantly.  Since we
> don't see any real reasons why high-end paint work could not be done
> entirely in 32-bit float, this is a reasonable thing.  Obviously, for a
> general paint tool like gimp, there is no question of maintaining 8-bit
> support.  For us, the need to maintain this kind of flexibility with the
> code and independence from non-high end feature requirements far outweigh
> any software engineering ideals.
i have been watching Sven gently break it to the artists that newer
gimps might not be able to index until time to save.  and truly,
indexing is a terrible thing to do to an image, except the GIMP index
changes and reduces the number of colors so nicely.  that is just one
mode.  i use the other modes (grayscale i guess is left) as plug-ins
demand them.  it seems like the plans for the gimp i use has been to 
strip many many of the plug-ins from it, which is fine by me.  overdue 
even.  could the image modes be stripped also and made into plug-ins?

i am trying to make sense of this paragraph of the R&H post.  i think it
says that if many of the things in the gimp core were split off, into
plug-ins say, then development could continue in many camps and work not 
be duplicated.  


Gimp-developer mailing list

Reply via email to