Large coordinates in the X server

[Robert Morell]

On Fri, Dec 12, 2014 at 08:43:33AM -0800, Keith Packard wrote:
> * PGP Signed by an unknown key
> 
> Robert Morell <rmorell at nvidia.com> writes:
> 
> >> b) Change the X server's DDXPointRec type from 2xINT16 to 2xINT32; Convert
> >>    16-bit values from the protocol to 32-bit values as soon as we get them from
> >>    the wire, and do most internal processing of coordinates with 32-bit numbers
> 
> > Since this has been met with crickets, I'm going to forge ahead with
> > option b) for now.  If you have any objections to this, please bring
> > them up sooner rather than later.
> 
> I'd much rather the X server not transform all of the incoming data in
> the DIX layer, and rather perform that translation in the rendering
> code. Copying all of the incoming data will have a fairly dramatic
> effect on performance.

Hmm, I guess that depends on whether we're already fetching coordinates
directly out of the request "fresh off the wire", or copying them.  If
there is already a copy, then scaling up to 2x wider integers may
admittedly trash 2x more cachelines on write, but I wouldn't expect
anything too drastic.

> How about just removing miTranslate from the GC and forcing the
> spans rendering functions to deal with translation themselves? That way
> the mi code would operate purely in window coordinate space. The fb code
> would require the addition of a couple of lines of code, and glamor
> would actually have some code deleted.

Interesting idea.

I think "a couple of lines of code" is a bit optimistic for how much
libfb would need to change :)

Xserver-spec.xml has an interesting point here about how miTranslate was
intended to be used, depending on hardware support (sorry for the large
quote):

    However, the mi routines can translate (relocate) the points from
    window-relative to screen-relative if desired.  If you set the
    miTranslate field in the GC (set it in the CreateGC or ValidateGC
    routine), then the mi output routines will translate all coordinates.
    If it is false, then the coordinates will be passed window-relative.
    Screens with no hardware translation will probably set miTranslate to
    TRUE, so that geometry (e.g. polygons, rectangles) can be translated,
    rather than having the resulting list of scanlines translated; this is
    good because the list vertices in a drawing request will generally be
    much smaller than the list of scanlines it produces.  Similarly,
    hardware that does translation can set miTranslate to FALSE, and avoid
    the extra addition per vertex, which can be (but is not always)
    important for getting the highest possible performance.

In the case of miFillPolygon, for example, the polygon is decomposed
into spans by miFill{Convex,General}Poly().  The number of points which
need to be translated by the lower rendering layers after it's been
decomposed is potentially much larger than the initial polygon
coordinates.

Anyway, there are some performance tradeoffs here that aren't
immediately obvious.  Unless anyone has any better ideas, I'll look into
writing up some preliminary changes to compare.

- Robert