Conference bulova::decw_jan-89_to_nov-90

#include  <decw$include/xlib.h>
#include  stdio
#include  errno
#include  math

/* Define size of drawables */
#define XMIN 0
#define YMIN 0
#define XMAX 800
#define YMAX 800
#define Window1Name "Circle"

#define DTOR 3.14159/180.0                   /* Degrees to radians convertion */
#define RADIUS  380                                       /* Radius of circle */
#define XORI   400                                      /* X offset of origin */
#define YORI   400                                      /* Y offset of origin */

Display   *dpy = 0 ;
GC        gc1 ;
Window    win1 ;
float     delay = 3.0 ;

void setup() ;
void circle() ;

main()
{
  int     npts ;                            /* Number of points in the circle */
  char    *junk ;

  setup() ;

  printf("Enter value for no. of points [int] : ") ;  scanf("%d", &npts) ;
  circle(npts) ;

  printf("Enter any string to exit : ") ;
  scanf("%s", &junk) ;
}

/** -------------------------------- End of main --------------------------- **/

void setup()
{
  Screen   *screen ;
  XSetWindowAttributes xswa ;

  dpy = XOpenDisplay(0) ;
  XSynchronize(dpy, 1) ;

  screen = DefaultScreenOfDisplay(dpy) ;

  xswa.background_pixel = XWhitePixelOfScreen(screen) ;

  win1 = XCreateWindow(dpy,
         RootWindow(dpy, DefaultScreen(dpy)),
         100, 100, XMAX-XMIN, YMAX-YMIN, 0,
         DefaultDepthOfScreen(screen), InputOutput,
         DefaultVisualOfScreen(screen), CWBackPixel,
         &xswa) ;

  XStoreName(dpy, win1, Window1Name) ;
  XMapWindow(dpy, win1) ;

  gc1 = DefaultGC(dpy, DefaultScreen(dpy)) ;                      /* Get a GC */

  /* Set up to draw black lines on white background */
  XSetForeground(dpy, gc1, XBlackPixel(dpy, DefaultScreen(dpy))) ;
}

/* -------------------------------------------------------------------------- */

void circle(npts)
  int npts ;
{
  int      ii ;
  float    var_1 ;
  XPoint   *points ;

  /* (Bytes per int) * (ints per point) * (number of points) */
  points = malloc(sizeof(XPoint)*npts) ;
  if (points == 0) {
    printf("Unable to malloc %d points\n", npts) ;
    exit(vaxc$errno) ;
  }                                                    /* .. if malloc failed */

  var_1 = ( (double)360 / (double)npts ) * DTOR ;      /* Simplify expression */

  for (ii=0 ; ii<npts ; ii++) {
   (points +ii)->x = (short)( (double)RADIUS * sin((double)ii * var_1) +
                                                          (double) XORI ) ;
   (points +ii)->y = (short)( (double)RADIUS * cos((double)ii * var_1) +
                                                          (double) YORI ) ;
  }                                                      /* .. for all points */

  XDrawLines(dpy, win1, gc1, points, npts, CoordModeOrigin) ;            /* ? */
  printf("After DrawLines\n") ;
/**  lib$wait(&delay) ; **/
/**  XFillPolygon(dpy, win1, gc1, points, npts, Complex, CoordModeOrigin) ; /* ? */
/**  XFillPolygon(dpy, win1, gc1, points, npts, Convex, CoordModeOrigin) ; /* ? */
/**  XFillPolygon(dpy, win1, gc1, points, npts, Nonconvex, CoordModeOrigin) ; /* ? */
  XFillPolygon(dpy, win1, gc1, points, npts, Complex, CoordModeOrigin) ; /* ? */
  printf("After FillPolygon\n") ;
/**  lib$wait(&delay) ; **/
}

    We ran into this while developing UISX.  We found that we can get
    consistent action as long as week keep the list passed to XDrawSegments
    to no more than 8184 segments;  XDrawLines can take up to 32744 points;
    XFillPoly can take up to 4092 and remain consistent.  If we went over
    any of these limits we got inconsistent behavior.  Sometimes it crashed
    the server (When the system appears hung above, restart the server and
    then look in the old server error log.  We found errors about bad
    packets in there).  Other times it gave strange messages about a bad GC.
    
    You are right that this is not documented.  I'm told that it's a bug
    and that the X client side seems to be over running a packet instead of
    breaking it properly.  We found the above values by trial and error. 
    We've had to resort to having our code break the calls down into
    multiple calls to get this to work.
    
    Irene

The XMaxRequestSize() Xlib function will tell you the size of the
largest request you can make.  The X protocol requires that this number
be no smaller than 16384 bytes.  This works out to 4093 points in
XDrawLines, 4092 points in a XFillPolygon, and 2046 segments in a
XDrawSegments.  A particular implementation is allowed to exceed these
limits and, in fact, DEC implementations are able to work around it for
XDrawSegments and XDrawLines.  No help for XFillPolygon, though.

Ken

I've tried running the example program on a VMS V5.5-1 system with the display 
directed to a DECstation running Ultrix V4.0, using both TCP/IP and DECnet 
transport. This way it runs O.K. up to over 16000 vertices, but crashes with 
17000 vertices thus:

ZSAZSA>run xcircle
Enter value for no. of points [int] : 17000
X error event received from server:  BadLength - request length incorrect; inter
nal Xlib error
  Failed request major op code 69 (X_FillPoly)
  Failed request minor op code 0 (if applicable)
  ResourceID 0x100001 in failed request (if applicable)
  Serial number of failed request 10
  Current serial number in output stream 11
%XLIB-E-ERROREVENT, error event received from server
%TRACE-E-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

                                                           00064470  00064470
                                                           00064295  00064295
                                                           00065BE3  00065BE3
                                                           00065004  00065004
                                                           0005C43A  0005C43A
                                                           0005C2CE  0005C2CE
                                                           00082DD0  00082DD0
XCIRCLE         circle                           2543      000000F3  0000063F


I got the same result with a DECstation running UWS 2.2.


Richard

    What is VMS V5.5-1?  Last I heard V5.4 is still in field test.
    
    Irene

Probably V5.3-1....

	Steve

VMS 5.5 comes up on my VAXstation when the operator has 5 thumbs on each hand 
(and no fingers)!

Sorry for the confusion (should be VMS V5.3-1)

Richard

The Phigs boys tell me that this problem is caused by a limit in the transport 
buffer size which is operating system dependent. On Ultrix, this
limit is, by default, usually 64K (16386 points * 4-bytes-per-point), and on
VMS usually 16K (4096 points * 4-bytes-per-point).

Is there any way I can modify this buffer size on VMS?


Richard

    This is not so much an OS limitation, as one imposed by an X server.
    At the time you open a display, it sends back a message which says
    how big a request it is willing to accept.  I think the protocol
    requires you to support at least 16KB.
    
    I think that it is the responsibility fo Xlib to partition large calls
    into requests which fit in 16KB.  If it is not doing so on your client
    platform, then that is a bug, and should be reported.
    
    James