Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  how to XDrawLines > MaxRequestSize
Message-ID: <9106122314.AA17431@lightning.McRCIM.McGill.EDU>
Date: 12 Jun 91 23:14:28 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 59

> I hadn't realized that there was a limit to the size of the lists
> that the X poly requests like XDrawLines can handle until recently,
> when I read Kenton Lee's article 'Behind Curtain X' in June's Unix
> Review.  Here's some code which will draw lines with an arbitrary
> length array of points.

[code omitted; simply breaks up the list of points, calling XDrawLines
 multiple times.]

> A couple of pointed questions:
> - If it's so simple, why can't the Xlib do it for you?

Because it's *not* so simple.  Read the protocol spec for the PolyLine
request.  In particular, pay close attention to joins and the semantics
of overlapping lines.  Your "solution" produces at least the following
violations:

- Between batches of lines, the line cap is applied twice instead of
  the line join being applied once.  The protocol document says:

	The lines join correctly at all intermediate points, and if the
	first and last points coincide, the first and last lines also
	join correctly.

- When wide lines intersect, the overlapping pixesl are drawn either
  once, if all overlapping pieces fall in the same batch, or multiple
  times, if not.  The protocol document says:

	For any given line, no pixel is drawn more than once.  If thin
	(zero line-width) lines intersect, the intersecting pixels are
	drawn multiple times.  If wide lines intersect, the
	intersecting pixels are drawn only once, as though the entire
	PolyLine were a single filled shape.

The Xlib document contains similar language in both cases.

> - Xlib should at least tell you the exact number of points you can
>   give to each request, instead of making you divide by the size of
>   the array element and subtract the header size...

Arguably so, but you'd have to have a separate value for each
draw-multiple-things routine.  While this is not particularly onerous,
because there are only a few things which generate huge requests which
can't be split up (lines, rectangles, arcs, and filled polygons are all
I can see offhand), it is somewhat ugly.

> /* allow for X protocol request header; 3 is supposed to be enough
>  * for now, but there's no guarantee this will not change...
>  */
> #define FUDGE 10

It won't change without a pretty major protocol revision; the size of
the PolyLine overhead relative to the size of each line is fixed by the
encoding.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu