Re: gdk-pixbuf Lanczos scaling support

[Owen Taylor <otaylor redhat com>]

On Sat, 2003-03-08 at 15:43, Mark Schreiber wrote:
> If I run out and write a patch to add support for the Lanczos scaling
> algorithm to gdk-pixbuf, even though doing so would add another
> scaling type, is there any chance that it would get added, or are the
> scaling types, being part of the API, fixed in stone between major
> releases?

They are definitely part of the API, so any filter additions would
have to be added in a release where we add API - 2.4, 2.6, ...

The more subtle question you may be asking is "is it a _compatible_
API change". There is frequently a problem with extending enumerations
since someone could theoretically have written:

 char *name;

 switch (filter_type) {
 case GDK_PIXBUF_NEAREST:
   name = "nearest";
   break;
 ...
 case GDK_PIXBUF_HYPER:  
   name = "hyper";
   break;
 }

 printf ("The filter type is %s\n", name);

But a policy of never extending enumerations is pretty limiting, so
we've sometimes made exceptions (for instance, in 2.2, we extended
the GdkWindowState flags enumeration.)

"is it at all likely that someone would have switched over this
enumeration"? is a relevant question.

> Lanczos seems to be relatively slow, but produces top-notch results
> for nearly all images -- the excellent freeware IrfanView for Windows
> uses it for scaling, and ImageMagick uses it as the default scaling
> algorithm.  Gqview, on the other hand, has only HYPER, as gdk-pixbuf
> lacks support for Lanczos.

HYPER, as specified (but not as actually currently implemented)
should be a filter similar in quality to a Lanczos-windowed 
sync function. (Or perhaps better ... when Raph wrote down what
it should be, he tried to pick the "best" available filter
based on the literature.)

Since I think 99.9% of the users of the library would have no
rational reason to pick one or the other, having both doesn't
make a lot of sense to me. It would be better to fix HYPER.

Regards,
                                   Owen