Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!decvax!decwrl!jumbo!jg
From: jg@jumbo.dec.com (Jim Gettys)
Newsgroups: comp.windows.x
Subject: Re: 128k request limit
Message-ID: <781@jumbo.dec.com>
Date: Tue, 14-Apr-87 12:22:08 EST
Article-I.D.: jumbo.781
Posted: Tue Apr 14 12:22:08 1987
Date-Received: Sun, 19-Apr-87 00:26:14 EST
References: <8704140212.AA20120@ucbarpa.Berkeley.EDU> <870414083107.2.RWS@KILLINGTON.LCS.MIT.EDU>
Reply-To: jg@jumbo.UUCP (Jim Gettys)
Distribution: world
Organization: DEC Systems Research Center
Lines: 34

In article <870414083107.2.RWS@KILLINGTON.LCS.MIT.EDU> RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) writes:

>There will certainly be a function that returns the maximum.  As to the
>rest, I'll leave the definitive word to the Xlib designer (and prod him
>for a response), but I certainly believe there should be routines for
>the image requests that break data into chunks, so that callers don't
>have to keep reinventing this wheel.   It's unclear whether the
>"standard" interface should generate an error on oversize data or
>decompose, since the latter does change the semantics with respect to
>indivisibility.  Note that the same sorts of issues can also arise in
>other requests (e.g., most of the Poly graphic requests).

My current thinking on the topic is to break image requests up into chunks
behind the back of the caller (not yet implemented as of this instant, but
on the agenda for the next month) for XPutImage.  

There are at least three strategies for the graphics requests (BTW, it is
very unfriendly to other clients to make single huge requests unless
unavoidable, as you will be locking other clients out for the duration;
one might consider an application sending tens of thousands of vectors
as a single poly request broken in the first place).

	1) return an error while suppressing the request, making the client
fully responsible for breaking up the request into more bite size chunks.
	2) split the poly request up into smaller requests. This has
semantic difficulties at the break point for some of the graphics
operations (in particular join semantics, or some fill operations).
	3) truncate the request silently.

The problem with 1) is that I suspect most programs won't bother to
check for the error and handle it, 2) sometimes gets somewhat wrong answers
on large requests, and 3) wimps out entirely, giving you very wrong
answers.  I currently lean toward  2, but am very open to suggestions
at this point.