On 16 Dec 2011, at 04:18, Greg Ercolano wrote:

>>> X_CreatePixmap: BadValue (integer parameter out of range for operation) 0x0
>>> X_CopyArea: BadDrawable (invalid Pixmap or Window parameter) 0xa00043
>>> X_FreePixmap: BadPixmap (invalid Pixmap parameter) 0xa00043
> 
>> I have no local access.
> 
> 	Just curious: when you say there's "no local access",
> 	does this mean you're using a remote desktop,
> 	or is the app running over a remote X display?
> 	(export DISPLAY=someremote, etc)
> 
> 	Perhaps the messages are showing up when the tile size
> 	approaches 0 in width or height, and this is causing
> 	the remote X display mapping to print those errors.
> 
> 	If so, probably the way to avoid the errors would be
> 	to prevent the tile program from sizing a tile smaller
> 	than zero on width or height, as it seems to be exposing
> 	these errors.
> 
> 	Or, perhaps we're doing something wrong in FLTK when it
> 	comes to our X calls when dealing with windows of zero
> 	width or height.


Summarising what I think is happening, for anyone who is following along at home. Though I may be totally wrong...

It seems that David (the OP) is running into issues with the tile sample from the test folder, in particular if the subwindow tile resizes to zero, when he is getting X_CreatePixmap errors, as seen above.

But: 

This only happens (I think) if he is running the code on a 64-bit linux box, rendering to a X-server display (Exceed on a Windows machine.)

If he tries the same test on a 32-bit linux box, rendering to the same X-server, it seems to work OK.

If he runs the code locally on the Windows box, it seems to be OK.

Both Greg and I have tried a few linux versions and have not been able to reproduce the failure.

So, um, I *think* those are maybe *the facts*. Or maybe not.

Anyway, what I think may be interesting is that, from David's work, it appears that the code path that chokes is the path through Fl_Double_Window's flush() method, on an X11 host that *does not* have XDBE support. 
(See Fl_Double_Window.cxx, line 338 of r9209)

In that case, the double window is created by buffering in an Fl_Offscreen, and it this buffering that appears to be choking, since it seems that, in some cases, the offscreen is not valid (presumably when we try a create a zero-sized offscreen on a 64-bit machine, it would appear.)

Now, I have not been able to reproduce this at all (I don't currently have any 64-bit machines, either real or in my VM's, though I guess I could create one...) and the machines I do have seem to report that they have XDBE so don't take the suspect code path anyway...

So, in my normal testing (and I guess most peoples since XDBE is pretty common now I think?) we would not hit this code path, so there may be a latent bug here we have never seen in testing? Though it may be of great antiquity... Maybe it only manifests on a 64-bit linux box without XDBE support, which *might* be an uncommon combination...?

A related question might be why the 32-bit linux works whilst the 64-bit does not, but that may well be some subtle difference in the way the X client code on the 32/64 bit versions behaves.

(TANGENT: 
I know that when I started doing some 64-bit linux stuff a while back, I hit a bunch of weird behaviours that looked like bugs to me, but the Xorg folks closed all my bugs as being "as intended"... Which I guess was fair enough, because if you read the docs, then applied the interpretation they were, you could see that what they did *might* reasonably be a valid interpretation of what the docs said, but... you know, it was all a bit weird anyway... 

On a slightly related note, I stopped using Exceed as an X-server on Windows because it was doing some weird s**t too, so now I mainly use Xming instead and that has been better. Though I do not know if that is pertinent to David's observations or not in this case.
/TANGENT)

So, that's where we are I think.

Corrections and comments welcomed...