[cairo] pixman: Branch 'master'

[Soeren Sandmann]

Carl Worth <cworth at cworth.org> writes:

> On Fri, 29 Feb 2008 15:48:29 -0800 (PST), Søren wrote:
> > +  - Moving to 24.8 coordinates. This is tricky because X is still
> > +    defined as 16.16 and will be basically forever. It's possible we
> > +    could do this by adding extra offset_x/y parameters to the
> > +    trapezoid calls. The X server could then just call the API with
> > +    (0, 0). Cairo would have to make sure that the delta *within* a
> > +    batch of trapezoids does not exceed 16 bit.
> 
> I'm not sure that the offset idea will cut it.
> 
> One of the first justifications that Mozilla gave for wanting to do
> larger-than-16-bit coordinates was for a giant scrollable region that
> greatly exceeds the current pixmap. Obviously they'll draw only items
> that are actually visible on the current region of interest, but one
> of those items can be a full-size background-color rectangle.
> 
> So in that case, there's a single trapezoid with top and bottom
> coordinates that don't fit into the 16-bit limit.

Yes, gigantic trapezoids and batches of trapezoids that span more than
16 bits of coordinate space would have to be broken up.

We could have a helper function within pixman that could do this:

    pixman_split_traps (const pixman_trap_24_8_t *traps, int n_traps, 
                        void (* callback) (
                                const pixman_trap_t *traps, int n_traps,
                                int x_offset, int y_offset));

that would do the splitting.

> Meanwhile, I really don't see why changing pixman will cause any
> problem for the X server. I mean, it's not as if the Render protocol
> guarantees that all trapezoids will be accurately rendered within a
> 16-bit sub-pixel grid, (that doesn't even make sense with only 8 bits
> of alpha per pixel, for example).

The advantage of a scheme like the above is that the X server would
require basically no code changes, just adding "0, 0" in a few
places. 

With a move to 24.8, at the very least the 16.16 protocol input would
have to be explicitly converted to 24.8.

Of course, this could also be done by a helper function in pixman; the
main difference is that X has 16.16 input set in stone in a widely
used API, whereas cairo doesn't.

Also, the Render protocol does specify exact pixelation:

    Rasterization

    Alpha values are generated by point sampling the coverage of a square
    surrounding the center of each pixel by the polygon.

    In Precise poly mode, the sample points are located in a regular
    grid.  When alpha depth 'e' is even, the regular grid is 2**(e/2)
    + 1 samples wide and 2**(e/2) -1 samples high.  For odd alpha
    depth 'o', the sample grid is 2**o - 1 samples wide and 1 sample
    high.  Note that odd alpha depth usually occurs only at depth 1,
    so this misshapen sample grid has no ill effects.  The sample grid
    is centered within the pixel and then each sample point is rounded
    down to a point on the sub-pixel coordinate grid.

The way I read this, rounding to 8 bits would not be correct.

I do know that there are several good reasons to disregard or change
the Render rasterization rules. I also don't know if we actually
implement the above algorithm currently.

The TODO file is a bit misnamed. Generally it does contains things
that need to be done, but the discussion items there are just
discussion, not a fully-formed masterplan. Think of it as a low-tech
wiki with a better user interface.


Soren