Large coordinates in the X server

Robert Morell rmorell at nvidia.com
Fri Nov 14 08:29:11 PST 2014


Hi,

I have been experimenting with root window sizes that meet the coordinate space
limits of the X11 protocol -- 32767 for both width and height.  Unsurprisingly,
this doesn't work as well as one might hope, even for very simple tests.  One
example is 'xlogo'.  With a 32767x40 root window, running:
`xlogo -geometry 40x40+32726+0`
works as you'd expect.  But running:
`xlogo -geometry 40x40+32727+0`
appears corrupt.

It looks like what's happening is that xlogo [1] is making a bunch of
FillPolygon requests, and some of the coordinates extend beyond the window's
clip region.  Normally this is fine, and the polygon is just partially clipped
away.  miFillPolygon [2] will translate the points by the window's origin, but
in this case, the translated point overflows DDXPoint's 'INT16' type, and the
polygon ends up getting rendered from the far negative end of the coordinate
space rather than the far positive end.

I'm sure that this is only the tip of the iceberg.  There are a few different
ways that I can think of to deal with this:
a) Carefully check for overflow everywhere that translation (or other
   coordinate manipulation) is performed
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
c) Assert that this is a bug in the application and don't fix it; instead,
   (attempt to) fix applications as necessary

Of those options, it seems to me that:
a) is very difficult to get right everywhere, and would introduce a lot more
   processing overhead than is necessary
b) is an unfortunately intrusive change, but hopefully would "just work" once
   everything is updated
c) isn't really an option; besides being too much code to realistically change,
   dragging a window off the end of the root window could still result in
   translated coordinates which legitimately extend beyond the end of the
   coordinate system.

So my vote would be on b).  Does anyone have any objections to this, or better
suggestions?


[1] xlogo calls Xmu to actually draw the logo:
    http://cgit.freedesktop.org/xorg/lib/libXmu/tree/src/DrawLogo.c
[2] http://cgit.freedesktop.org/xorg/xserver/tree/mi/mipoly.c


Thanks,
Robert


More information about the xorg-devel mailing list