[cairo] Floating point API in Pixman

[Soeren Sandmann]

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

> There are several bugs in the Cairo port of Inkscape that are caused
> by the 16.16 fixed point coordinate format in Pixman. We can't switch
> to Cairo until this is resolved, mainly because Inkscape is used to
> render OpenStreetMap tiles and must be able to cope with very large
> images - so in addition to supersampling, I would like to work on
> floating point API in Pixman.

How large are the images that inkscape needs to deal with? There is
currently a limitation in cairo of +/- 2^23, which is about +/- 8.3
million. This is also about the approximate range of integers that can
be stored exactly in a single precision float.

> I note that there are some functions in pixman.h that start with
> pixman_f_ and operate on floating point matrices. However, they appear
> unused at the moment.

They are used in the X server.

> What is the best approach to introduce floating point-based API?
> Should I add a new function starting with pixman_f_ for each Pixman
> call that accepts fixed point coordinates? What about matrices that
> are part of other data types, such as pixman_image_t - should there be
> a compile time flag that selects which type of matrix is used?

For the matrix in pixman_image_t, I think we need to just move to
single precision floating point unconditionally. There are several
cases where 16.16 fixed point simply doesn't have enough either range
or precision. See

        https://bugs.freedesktop.org/show_bug.cgi?id=15355

for example.

For the gradients, the same thing applies. They need to be done in
floating point unconditionally both to fix the bugs you recently
pointed out.

The other major piece of API that uses fixed point is the
trapezoids. In this case, there is a pretty good reason for it: you
don't want to get different antialiasing based on how far from the
origin the trapezoid is. But moving to 24.8 coordinates internally
might be a good idea. I'm not sure in which cases cairo is actually
using the trapezoids these days.

As for naming the api calls, I never liked the _f_ convention, but
couldn't think of anything better at the time. Maybe we need
shorthands for the various types that pixman deals with, for example:

        sp:    single precision
        dp:    double precision
        fix16: fixed point 16.16
        fix24: fixed point 24.8
        fix48: fixed point 48.16
        un8:   normalized 8 bit (ie., [0,1] mapped onto [0,0xff])

and so on. Then natural names for the new functions would be

        pixman_<old name>_sp() 

for functions that took single precision arguments. 

I'm open to suggestions. On the other hand, the naming is a fairly
minor concern compared to actually writing the code.


Soren