Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re: Window sizes in X11R3
Keywords: X11R3 Window
Message-ID: <1347@acorn.co.uk>
Date: 11 Jan 90 10:21:22 GMT
References: <890@ontek.UUCP>
Reply-To: john@acorn.UUCP (John Bowler)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 33

In article <890@ontek.UUCP> eric@ontek.UUCP (Eric Hanson) writes:
... [explanation of problem - windows bigger than 32k] ...
>And now for the questions...
>1)  Does this mean that the largest allow widget size is 32K?
>2)  What would happen if I changed Position & Dimension in
>    Intrinsic.h to ints, and remade X?
>3)  Am I insane for wanting such big windows?

rws then answers 1/2 by pointing out that the protocol uses 16
bit quantities in the relevant cases.

More than this, even if you have a ``reasonable''' size window you
cannot rely on the graphics operations clipping drawing operations
which are too far (more than 15 bits) outside that window.  This will
arise, for example, if you have an application which allows you to
``zoom in'' on an image.  For example, a CAD package where you can zoom
in arbitrary amounts on a part of a wireframe display (this is a
practical example which I have encountered before on the Aegis native
window system, which has similar restrictions).  This is because the
protocol representation of a point is [INT16, INT16].

Of course, in the CAD example the application will almost certainly
clip the lines before drawing them, to avoid the network overhead of
totally redundant draws.  However, the obvious way of doing the
clipping (using the Sutherland-Cohen algorithm) is not adequate - it
will leave in very long lines which happen to cross the viewing
area...  This is what caught us out on Aegis.

Notice that the protocol allows you to create a window which is 65535
pixels wide - but it is very difficult to draw into three quarters
of it :-)

John Bowler (jbowler@acorn.co.uk)