[cairo] 32k limit with image surface?

[Soeren Sandmann]

Carl Worth <cworth at cworth.org> writes:

> But pixman still uses 16.16-bit fixed-point integers, so cairo has to
> convert to that for some operations (such as trapezoid rasterization),
> which can be buggy due to data loss as you've noticed. So to eliminate
> more bugs we will want to either teach pixman to accept 24.8-bit
> integers instead, or else code things up in such a way to avoid all
> 16.16-bit interfaces in pixman for the image backend.

Apart from the trapezoid limitation, there is also one in that

        pixman_image_composite()

limits its coordinates to 16 bit. 

If it's useful, I'd be fine adding a pixman_image_composite_32() for
0.16.0. There are a few 16 bit limitations left internally here and
there, but I think all of them are trivial to fix. Clearly,
pixman_image_composite() could just call the 32 bit version.

The trapezoid limitation is trickier because the X server has 16.16
set in stone in its API. There are various things that could be done:

   (1) Add a copy of the trapezoid implementation that uses 24.8
       coordinates; then use this path from the image backend.

       I am not thrilled about this one because it would either add a
       bunch of new code or more complex build-time code
       generation. And trapezoids are falling out of favor.

   (2) Make the current trap implementation use 24.8 internally, and
       add new 24.8 API for trapezoid rasterization. 

       This would make X trapezoids happen with eight bits of subpixel
       precision instead of sixteen, but I don't think anyone would
       even notice.

   (3) Add a polygon image, then use that from the image backend.

       This is a good chunk of work, but it would pay off not only in
       higher range, but also in better performance because polygon
       rasterization is more efficient than tesselate-then-trap, and
       because geometry rendering could then ahppen in one pass. By
       adding a polygon picture type to XRender, this would also allow
       better performance for the X backend.

Of those, I'd prefer (3), but if someone wants to do (2), I would
probably take the patch.



Soren