Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: doug@genmri.UUCP (Doug Becker)
Newsgroups: comp.windows.x
Subject: Re: BadLength for XDrawLines
Message-ID: <9102201904.AA06694@genmri.sane.COM>
Date: 20 Feb 91 19:04:02 GMT
References: <9102182000.AA09355@iris49.biosym.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 33

Are you discussing R3 or R4?

    There is no function or
    macro to get this from the display structure.

In R4, there is the XMaxRequestSize function.  R3 users will have to use
dpy->max_request_size directly.
    
    To forestall further questions, in general, Xlib cannot breakup such
    requests into multiple calls because the requests may depend on
    previous values.  For example:

As far as I know, the situation in MIT's R4 Xlib is this: In the case of
XDrawPoints, CoordModePrevious can be (and is) handled by Xlib.
XDrawRectangles also breaks up its requests.  The plural PolyText{8,16},
PolySegment, and PolyFillArc request generating functions split up their
requests as well.

The XDrawLines and XDrawArcs functions do not break up their requests
because of the wide-line intersection and joining specifications of those
calls, as you mentioned (this is conjecture on my part).  

The partitioning of poly protocol requests by Xlib is definitely a grey
area, one I'm hoping will be addressed in R5 (if nowhere else then in the
Xlib spec).  I've mentioned this situation to a couple of people at MIT are
in a position to do something about it; the last I heard was that MIT would
investigate it.

-- 

Doug Becker
doug@nmri.ge.com
crdgw1.ge.com!sane!doug