home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / windows / x / 20197 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.3 KB  |  56 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!era!feit
  3. From: feit@ERA.COM (Mark Feit)
  4. Subject: Re: Success! Eureka!  Cancel that last post...
  5. Message-ID: <1992Dec14.185340.17751@ERA.COM>
  6. Sender: feit@ERA.COM (Mark Feit)
  7. Organization: Engineering Research Associates, Vienna, VA
  8. Date: Mon, 14 Dec 1992 18:53:40 GMT
  9. Lines: 45
  10.  
  11. On comp.windows.x, esr@snark.thyrsus.com (Eric S. Raymond) posts:
  12.  > The bad news is that the way I found to make this work was to use a
  13.  > series of XFillRectangle() calls in place of a single
  14.  > XFillRectangles().  I now believe that there is a bug or undocumented
  15.  > limit in the generic XFillRectangles code itself that was causing this
  16.  > problem.
  17.  
  18. The deep dark truth of the matter is that your server (everybody's,
  19. actually) has a limit on the number of bytes that can be transmitted
  20. in a single request.  The XFillRectangles() function (on the source
  21. tape in mit/lib/X/XDrRects.c, if you're interested) isn't smart enough
  22. to split large requests into multiple batches, and anything beyond the
  23. limit gets tossed.
  24.  
  25. The limit on the number of rectangles you can draw in a single call to
  26. XFillRectangles() is easy to figure out:
  27.  
  28.     max_rectangles = ((XMaxRequestSize(display) * 4) - 12) / 8
  29.  
  30. The 12 bytes that get subtracted are for the request header, which
  31. contains an opcode, the length of the request, a drawable and the GC
  32. to be used.  That leaves the remaining space for rectangles at 8 bytes
  33. a pop.
  34.  
  35. I look at this approach as a hack (necessary, for now), since you
  36. still have to know something about the underlying protocol before you
  37. can figure out how many rectangles (or whatever) can be sent.  A fix
  38. for this isn't difficult and should probably be put in place for other
  39. similar functions.  Chances are that if the protocol changes sometime
  40. in the future and the Xlib interface doesn't, some programs are going
  41. to stop working.
  42.  
  43. Would someone in the know care to comment on why it is the way it is
  44. and whether or not there are any plans to make the fix?
  45.  
  46.                         - Mark
  47.  
  48.  ................................. .................................
  49. : Mark A. Feit             KD4TAJ : Internet: feit@era.com          :
  50. : Engineering Research Associates : USENET: ...!uunet!era!feit      :
  51.  ................................. .................................
  52.            "Keep BSD Free -- Boycott AT&T"
  53.  
  54.  
  55.  
  56.