On Tue, 11 Mar 2003 19:05:03 +0100
RaphaŽl Quinet <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Mar 2003 18:20:34 +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote:
> So don't do that, then! ;-) Nobody should rely on unspecified
But how should an end-user know that this is unspecied behavior?
I could not find anything in the documentation that came with
my version of the GIMP :)
> One day, someone could decide that the GIMP would work
> better by compressing tiles on-the-fly in memory and clearing the RGB
> data of fully transparent pixels in order to improve the compression.
> And then all hacks that were relying on unspecified behavior would
> suddenly break. Who is to blame? Not the GIMP developer, IMHO.
Who else do you think an end-user is going to blame?
Remember that end-users are in general horrible beings: they believe
that they know what they want to do and they even believe that the
GIMP is simply a tool that they could use. When that tool does not
do what they want it is always the tool that is wrong.
Another problem with end-users is that they don't really want to learn new
things. The first time they will notice that the GIMP removes color
information is when they start using it for a serious job with large
images. For unknown reasons end-users tend to have an extremely low
frustration tolerance when they are working on jobs that they consider
serious (this might have something to do with these things that they call
deadlines). Instead of being grateful that they have learned that they
were sinning, they will usually start complaining: "But it works fine
on this part of the image" or "But it worked 5 minutes ago".
> The one to blame is the one who has used a feature that was not supposed
> to be used.
But why does it have an unerase then?
> We could of course specify that all fully transparent pixels are
> always set to black. But this is not done currently because this
> would imply a small (or maybe not so small) performance penalty.
But how great is that penalty? At least this gives consistent behavior.
Gimp-developer mailing list