nanogui: Image size limit?
Subject:
RE: [nanogui] RE: Image size limit?
From:
"Martin Kajdas" ####@####.####
Date:
14 Jul 2006 16:11:10 +0100
Message-Id: <CF2BB830A62F914F848E5AD5FFF57AC2291531@mkmail.MKPROD.COM>
Looking at the client.c and GrBitmap (where it fails), I do not see the
division of transfers into MAXREQUESTSZ size chunks when in fact other
functions (not all) have this logic.
Should it also be implemented in GrBitmap and it was not?
Why some functions have this and others do not? Oversight or playing lucky?
I guess that some functions do not expect the transfers to be large to begin with
but in case of BrBitmap it could happen (in my case 49000 bytes vs. 30000 limit)
Should I fix GrBitmap or the problem lies somewhere else?
Martin
-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Thursday, July 13, 2006 4:34 PM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] RE: Image size limit?
> One assert error message that may have something to do with it:
in nxproto.c line 41, in function nxAllocReq tests the size of the buffer to
be <= MAXREQUESTSZ which is printed to strerr as 30000.
Why is the assertion triggered and what is it for?
This checks the mechanism that always divvies up bitmaps
to be less than MAXREQUESTSZ bytes down the
line in a single nano-X packet. In this way, we won't
block a low-level socket write() nor try to write more
data than a simple system can handle. If this assert
fires, it means there's problems in client.c/srvnet.c,
which handle the packetizing of all requests.
Regards,
Greg
