Conference bulova::decw_jan-89_to_nov-90

The X protocol restricts window dimemsions to 16 bits.  Short of an extension,
there is nothing anyone can do about it.
				Jeff

    yes, but even if it is restricted to 16bits, when unsigned is used
    it should allow up to 65535x65535 surely?
    
    These bigger windows work on SUN running X server (rel. 2)
    
    Les
    

    The protocol defines POINT as four bytes encoded as two 16 bit SIGNED
    integers.
    
    A line drawn from (-1,-1) to (1,1) should be a very short line in the
    upper left hand corner of the screen.
    
    If interpreted as (65535,65535) to (1,1), that is as a very long line
    from the upper left hand corner of the screen to the lower right hand
    corner of the screen. Then that appears to me to be a very serious error
    in interpreting the X Protocol.

    Re .-1
    
    Can you explain how this refers to the creation of windows and why
    width and height are defined as unsigned ints in the reference manual
    (refering to XCreateWindow) and thus <65535 should be acceptable?
    
    Les
    

Width and height are unsigned, x and y are signed.  That allows you to do things
like placing a window which is larger than its parent with the upper left area
clipped by the parent.  (ie: parent is 10x10  child is 20x20 at location -5-5)

    Does this mean that if you position the window at -32767,-32767
    you can have a window sized at 65535x65535? and does this mean that
    it can't be moved?
    
    Les
    

    Another peice of info I just gleaned from him is that the Xserver
    throws an interger parameter out of range error when trying to create
    a window with a width or height bigger than 32767 no matter where
    the start position of the window is.
    
    Cheers
    Les
    

    Does anyone have any more information on .-1, .-2, the customer
    still wants to do this. Is this a QAR/SPR situation? or just the
    way of the world?
    
    Cheers for the help
    
    Les
    

It is the "way of the world".

You will not be able to create windows bigger than 32Kx32K using X windows.
The wire protocol reserves CARD16 for width and height.

-steve-

	If this is how it is, how come my customer can create bigger
    than 32Kx32K on X11R3 for SUN systems? Is it different or what?
    
    In hope ... Les
    

    CARD16 should mean 0..65535, so it would be possible, if people want to
    do the work, to support up to 64kx64k without wire protocol change.
    
    	paul

RE: CARD16 is 65535, not 32K-1.

You are so right.  Egg on my face.

-steve-

    Okay, 
    
    I think what you said is that this is *theoretically* possible,
    so why can't it be done? Is there a limit set somewhere in the kernel
    or in a similar parameter file somewhere that has to be changed
    to do this?
    
    Les

The problem is that coordinates are signed while widths and heights are
not.  That means that coordinates are in the range -32k to +32K while
widths and heights are in the range 0-64k.

Now this is all fine except that you frequently have to figure out all 4
corner coordinates.  If you calculate the right-most X coordinate by adding
the left-most coordinate and the width is greater 32K you overflow.  (You
can cons up other circumstances as well, where the width is < 32k).

The only solution to this is to convert all the internal arithmetic to 32bit.
This not only takes up memory, which heaven knows we use enough of already,
but also takes up developer time which could be spent on <choose your favorite
topic...say backing store>.  I'm not sure about the timings, but in could
conceivable make things slower too.  I don't remember.

Thus, the fix we came up with was to limit the width and height values
to 32k and return an error otherwise.

I would assume than any server which is running on a machine where "short"
is 16 bits, and which is based on the original MIT server would have the
same problem.  Sun, in the process of creating its merged X/NeWS product
totally rewrote the server.  If this is the version that your customer is
looking at, it may well be different.  It would not surprise me if Sun
decided to use all fixed or even floating point internally to accomodate
the PostScript-like NeWS model better.  This might make things slower.

Burns

    Since the Xprotocol defines the width as unsigned int, would it
    not be sensible and in line with the protocol to implement it as
    such. ie to have the 64kx64k window size possible?
    
    Is this a bug? Is it worth SPRing? The cust is porting a very popular
    database product to ultrix/DECwindows and seems to object to the
    differences/incompatabilities between our version of X and SUNs.
    
    Les
    

    Mmmmm,
    
    Does this mean that if you create a window at say 32K-4 of width
    say 500 then you can't actually write to the 496 rightmost pixels
    of the window?
    
    Sounds screwy to me
    
    Les
    

re .-1:  Talking about the protocol, at least, no.  Once you have created
your window at that location, then you talk about things in relative coordinates
and you can talk about stuff in the right 496 bits.  In terms of the existing
servers, yes.  Things may well break somewhere along the line.

re .-2:
Feel free to qar it.  Also tell us how much performance for ordinary cases
and how many features you are willing to give up to have a very unusual case
fixed.

That last sentence was a bit too caustic.  Sorry.  This is the kind of
tradeoff we need to make, though.  When we put in the workaround in version
one (sending an error if we discovered a width coordinate that was greater
than 15 bits), we did so because there some bugs in a few applications and
in the toolkit which accidently specified such widths sometimes (it was
subtracting n from m and getting a negative number which was interpreted
as a large unsigned number).  We have since had very few (if any other)
complaints...since X does not have a display list, very few people have
cared about having windows larger than the screen.  If you have customers
who need it, do put in a QAR.


Burns

    
    A corollory (I think thats what I mean) to this. 
    
    This problem doesn't arrise in the RISC implementation of the X
    server (according to the developer). Isn't there supposed to be
    common source and if so, when is this common source going to be
    in the VAX server.
    
    Les