eric@ontek.UUCP (Eric Hanson) (01/10/90)
I hate to interrupt the R4 discussion, but I've got an R3
question...
I've created a "graphing" widget (essentially a Window with
an extensive display routine) for my own work, which I
use inside of a standard Xaw Viewport Widget. On a recent, very
large, graph, I noticed the Viewport's scrollbars acting
strangely as I scrolled away from (0,0). After a little debugging,
I discovered that the graph widget's height exceeded 45,000 pixels
-- I overshot the magic 32767 limit on short integers.
A little research led to the following:
1) Widgets deal in "shorts." The x,y,width,height fields on
the core structure use types Position and Dimension, which are
defined as short and unsigned short in Intrinsic.h.
2) Windows use "int" for x,y,width,height, at least according to
the Xlib procedure params and the Window Attribute structures.
On my Sun 4, ints are 32-bit. Therefore, it would seem that X
would allow a 2 billion x 2 billion sized window.
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?
Sorry if any of this has been hashed out before, but would those in
the know please respond ASAP -- it's deadline time again!!
Thanks in advance,
Eric Hanson ...!uunet!ontek!eric
Ontek Corporation
Laguna Hills, CArws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/11/90)
2) Windows use "int" for x,y,width,height, at least according to
the Xlib procedure params and the Window Attribute structures.
On my Sun 4, ints are 32-bit. Therefore, it would seem that X
would allow a 2 billion x 2 billion sized window.
No, Xlib "lies" to you for the sake of a "wide type" interface. The
X protocol also deals in terms of 16-bit quantities.
3) Am I insane for wanting such big windows?
I can't attest to your mental condition, :-) but you are asking for trouble
if you use large windows (windows substantially larger than the physical
screen are "large"). Nothing really bad will happen until you overflow
15 bits. There's no guarantee at this point in time that servers (even
R4) will deal rationally with 15-bit overflow.john@acorn.co.uk (John Bowler) (01/11/90)
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)
daniel@mirsa.inria.fr (Daniel Dardailler) (01/11/90)
From article <9001101658.AA03153@expire.lcs.mit.edu>, by rws@EXPO.LCS.MIT.EDU (Bob Scheifler): > screen are "large"). Nothing really bad will happen until you overflow > 15 bits. There's no guarantee at this point in time that servers (even > R4) will deal rationally with 15-bit overflow. Why these 15 bits? Since window dimensions (CARD16 in the X protocol: 0+65536) are different from window positions (INT16: -32768+32768), my opinion is that with the viewport widget (or the Motif scrolledwindow as well) the toolkit tries to do a MoveWindow with an y > |32768| when the user scrolls too far (in order to generate an Expose event for the application), it looks like a dimension problem but it is a positionning one. For that matter, I have a question: why the Protocol (note the capital letter) does authorize 65536 pixels for the window dimensions if the (32768 - DisplayHeight) bottom pixels can never be exposed ?
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/12/90)
why the Protocol (note the capital letter) does authorize 65536 pixels
for the window dimensions if the (32768 - DisplayHeight) bottom pixels
can never be exposed ?
The Protocol defines the dimension values to be unsigned, since negative
values don't make sense. A side-effect was to yield a 16-bit value space,
but that wasn't the objective. It could well have explicitly specified the
maximum value of a dimension to be something smaller, but it doesn't. Of
course, an implementation can always impose a smaller size if it wants to
(e.g. generate an Alloc error).