[cairo] MIPMAPPING cairo.

[Carl Worth]

On Tue, 2008-10-14 at 14:29 -0700, Bill Spitzak wrote:

> I don't like there being lots of options for how to filter. This 
> counter-intuitively locks down the algorithm so that it cannot be 
> changed or improved in the future. For instance the default certainly 
> should not be BILINEAR but instead one of these new filters. However the 
> current Cairo api has the word "BILINEAR" in it.

The current cairo default is not BILINEAR.

> Users are interested in these settings:

Cairo does already have filter settings that are not
implementation-specific. The current modes that exist are FAST, GOOD,
and BEST and are documented as follows:

  CAIRO_FILTER_FAST: A high-performance filter, with quality similar
                     to CAIRO_FILTER_NEAREST
  CAIRO_FILTER_GOOD: A reasonable-performance filter, with quality
                     similar to CAIRO_FILTER_BILINEAR
  CAIRO_FILTER_BEST: The highest-quality available, performance may
                     not be suitable for interactive use.

It looks like the current documentation fails to point out the default,
but it is CAIRO_FILTER_GOOD.

Cairo does also provide implementation-specific filter values,
currently:

   CAIRO_FILTER_NEAREST: Nearest-neighbor filtering

   CAIRO_FILTER_BILINEAR: Linear interpolation in two dimensions

> 1. "nice" scaling. They don't care one bit about the algorithm.

That's what cairo already has as GOOD and it is the default.

> 2. "no antialiasing" which is the same as "nearest" here.

I think there are too different things here. One is "I want it to be as
fast as possible, and I don't care what it looks like". And FAST is
that. If the user specifically wants to say "no anti-aliasing" then one
can set CAIRO_FILTER_NEAREST. (Though we do also have
cairo_set_antialias (cr, CAIRO_ANTIALIAS_NONE) and maybe that should
change the default filter to NEAREST as well?)

> 3. *maybe* they are interested in "even nicer but slower". However in my 
> experience all backends eventually merge "nice" and "even nicer but 
> slower" into the same algorithm.

And we put BEST in place for this case. As you note, our current
implementation doesn't yet distinguish between GOOD and BEST.

> I recommend the Cairo api be more like this, with no implication as to 
> what the algorithm is.

So we've got that already. We just also let the application select a
specific implementation directly if desired. Maybe we'll decide to stop
adding implementation-specific filter values as we add more and more
filters, but I don't know.

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20081014/4a812b6f/attachment.pgp