[Pixman] [cairo] Supersampling - 1st attempt

[Soeren Sandmann]

Krzysztof Kosiński <tweenk.pl at gmail.com> writes:

> W dniu 11 sierpnia 2010 03:18 użytkownik Soeren Sandmann
> <sandmann at daimi.au.dk> napisał:
> >> 2. Shouldn't we use nearest-neighbor sampling to obtain subpixels?
> >
> > That's determined by what filter is being used in the call
> > bits_fetch_pixel_filtered(). So if you call
> >
> >        pixman_image_set_filter()
> >
> > with FILTER_NEAREST, then the subpixel will be obtained through
> > nearest-neighbor sampling. If you set it to LINEAR, then it will use
> > bilinear interpolation.
> 
> My point is that maybe the filter should affect the way the pixels are
> combined, not how the subpixel values are computed.

I'm not sure what you mean. The subpixels could certainly be combined
in a more sophisticated way than just averaging them (ie., using a
better filter than a box filter). I think that would be a useful
extension at some point.

> If there are many subpixels averaged together, it doesn't make a lot
> of sense to use an expensive method of computing them - the cheapest
> one (nearest-neighbor) might be sufficient.

Yes, in many cases, people would want to just use FILTER_NEAREST if
they are using a high sample rate. Ultimately, I think this decision
needs to happen outside pixman, although I could see a helper function

        pixman_image_set_transform_and_filters (image, transform)

that would compute reasonable filter choices for the transform in
question being useful.

> > - As you mention in a comment, it would be faster to compute fractions
> >  and then repeatedly add them. If this creates precision problems,
> >  maybe we need to look into using floating point.
> 
> What is the policy on floating point use in Pixman right now? It seems
> to use fixed point almost everywhere, even though this causes
> rendering artifacts, for example this one:
> https://bugs.freedesktop.org/show_bug.cgi?id)470
> 
> Maybe floating point / fixed point use should be determined at build
> time, so architectures with fast FPUs can get high precision while
> integer-only architectures can trade precision for performance?

I don't think integer-only architectures are all that interesting for
graphics. As far as I'm concerned, it's fine for pixman to require a
CPU with hardware floating point.

The main problem with moving to floating point is that all the test
suites will break. We'll need to figure out of to update that, but
fundamentally, I don't see a problem moving to floating point
unconditionally.


Soren