In modifying an existing application, which contained one (scrolled) DrawingArea and two (scrolled) Text widgets, I wanted to use multicolor text and decided to use two more DrawingArea widgets to accomplish this. However, only the 2000x2000 original Pixmap is reliably written for the refreshment of the original DrawingArea.
In order to accommodate the potentially long and/or wide range of text in the emulated Text widgets, I created a Pixmap of size 5000x4000 and 10000x2000, respectively. To be sure it wasn't something in the rendition of the text strings that was at fault in their unpredictable behavior, I drew a black 20x100 rectangle in the upper left corner of each Pixmap immediately after creation. Only the one for the 2000x2000 Pixmap appears in the associated DrawingArea window. Other than their sizes (and the variable names, of course), there is virtually no difference between these Pixmaps. In fact, if I temporarily change the dimensions of the other two to 2000x2000, I find that their behavior becomes reliable once again. None of the X documentation mentions any size limitations for the Pixmap, whose datatype is "opaque." (Thanks a lot, MIT!) Even if there were one, it should generate a predictable error message, rather than an unpredictable behavior. Anyway, even if "unsigned int" referred to 16 bits on my computer (which it does not), these dimensions would still be within range - for that matter, they would even be accommodated by "signed short"! Is this a known bug? If so, can I get around it, albeit kludgily, by declaring 21 variables of type Pixmap and doing redundant XDrawString() calls to be sure that any that might fall withing the bounds of the write will be updated, or is there a limit on the _total_ amount of memory available for Pixmap data? I am running under Windows NT4, SP3, with the Hummingbird Window Manager, v.6.1. (The window manager supplied with cygwin is impractical for any sophisticated applications.)