Re: [fltk.general] Tile sample and X_CreatePixmap error
I'm of the opinion (on the basis of inadequate tests by me!) that the crux is when Fl_Double_Window::flush() tries to create a zero sized Fl_offscreen surface. If we prevent it from doing so (which is what the OP's workaround did) then everything seems fine, even if the window is resized to 0,0. Whether we should allow zero-sized windows is probably a whole other question of course! -- Ian Sent, much to my surprise, from my iPhone ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
OK, I've opened STR #2797 for this.
Hopefully one of our X gurus can figure this out.
On 12/19/11 11:10, Greg Ercolano wrote:
> o The issue is definitely triggered when one of the tiles,
> probably 'child window' is resized to zero on either W or H.
> (I never saw negative numbers, so that's not an issue)
> I determined this by modifying resize() in src/Fl_Double_Window.cxx
> to print the W/H values. Errors only occur when W or H is zero.
>
> o I could easily prevent the problem by adding the following
> two lines of code to src/Fl_Double_Window.cxx's resize() method, eg:
>
> void Fl_Double_Window::resize(int X,int Y,int W,int H) {
> W = (W<=0)?1:W; // <-- ADDED THIS
> H = (H<=0)?1:H; // <-- ADDED THIS
> int ow = w();
>
> ..a hack which just prevents windows from possibly being
>resized to zero or less on W or H.
>
> If the OP's goal is to stop the errors, that seems to do it.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 12/19/11 10:23, Greg Ercolano wrote:
> On 12/19/11 01:40, Albrecht Schlosser wrote:
>> Greg, what happens if you configure FLTK in these cases with
>> --disable-xdbe?
> Yes, I can replicate the errors if I choose --disable-xdbe
> running locally on my centos 5.5/64 box.
>
> Good, looks like that's the issue; now that we can
> replicate, we can probably solve it easily.
OK, spent about 1/2 hour noodling.
In short: it's XDBE specific with Fl_Double_Window's only
getting sized to 0 on either width or height.
Details:
o Changing Fl_Double_Window -> Fl_Window prevents the errors.
So that seems to make it Fl_Double_Window specific.
o The issue is definitely triggered when one of the tiles,
probably 'child window' is resized to zero on either W or H.
(I never saw negative numbers, so that's not an issue)
I determined this by modifying resize() in src/Fl_Double_Window.cxx
to print the W/H values. Errors only occur when W or H is zero.
o I could easily prevent the problem by adding the following
two lines of code to src/Fl_Double_Window.cxx's resize() method, eg:
void Fl_Double_Window::resize(int X,int Y,int W,int H) {
W = (W<=0)?1:W; // <-- ADDED THIS
H = (H<=0)?1:H; // <-- ADDED THIS
int ow = w();
..a hack which just prevents windows from possibly being
resized to zero or less on W or H.
If the OP's goal is to stop the errors, that seems to do it.
That's about as far as I can go.
It's tricky to debug these X errors, because they don't appear
to occur when our code runs, due to how X buffers commands.
Is there a way to run an app in a mode where X operations
occur immediately, instead of being 'buffered'? If there was,
this might help debugging.
Or, if someone feels confident to debug this, please feel free.
Digging around in X is not something I'm good at.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 12/19/11 01:40, Albrecht Schlosser wrote: > Greg, what happens if you configure FLTK in these cases with > --disable-xdbe? Or did you? According to what Ian wrote, this > would be necessary to replicate the effect, if your system > used XDBE otherwise (the default). Hadn't tried it.. I'll give it a quick try now. (..) Yes, I can replicate the errors if I choose --disable-xdbe running locally on my centos 5.5/64 box. Good, looks like that's the issue; now that we can replicate, we can probably solve it easily. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 16.12.2011 18:42, Greg Ercolano wrote: > On 12/16/11 09:12, Ian MacArthur wrote: >> [32bit vs 64bit observations] > > Just to add some info to the mix: I tried a test between > two linux machines: > > 1) fedora 3 32bit/Xorg 6.8.1 (2004)/flwm > 2) centos 5.5 64bit/Xorg 7.1.1 (2006)/flwm > > I went on each, and ran both a local test of 'tile', and > also ssh'ing to the 'other' machine and running tile through > the DISPLAY. > > In all four cases (local on each, remote on each), no xlib > errors while moving around the tiles. (I didn't resize the window, > I just moved the tiles all around the screen to their extremes) > > So seems like this must be /very/ OS/Xserver specific. Greg, what happens if you configure FLTK in these cases with --disable-xdbe? Or did you? According to what Ian wrote, this would be necessary to replicate the effect, if your system used XDBE otherwise (the default). Sorry, I don't have enough time to do own tests, otherwise I'd try myself... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> On 12/16/11 09:12, Ian MacArthur wrote:
> > [32bit vs 64bit observations]
>
> Just to add some info to the mix: I tried a test between
> two linux machines:
>
> 1) fedora 3 32bit/Xorg 6.8.1 (2004)/flwm
> 2) centos 5.5 64bit/Xorg 7.1.1 (2006)/flwm
>
I have the same issue on Mandriva 11 32bits / Xorg 7.6.1
I change the config.h and comment the HAS_XDBE to force USE_X11 (line 110)
#if defined(USE_X11) || defined(WIN32)
printf("use X11\n");
myi->other_xid = fl_create_offscreen(w(), h());
clear_damage(FL_DAMAGE_ALL);
#elif defined(__APPLE_QUARTZ__)
use X11
X_CreatePixmap: BadValue (integer parameter out of range for operation) 0x0
X_CopyArea: BadDrawable (invalid Pixmap or Window parameter) 0x9c1
Else, it's working fine for xdbe
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
[...] > > 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. > May be not a 32/64 bits issues. I have no dev package available for RedHat 5.5 (32bits), so I used RedHat 4.5 for my tests. I will check the rpms version of xorg on next monday. I am off this weekend. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
[...] > > 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. > Hum, probably not a 32/64 bits issues. I have no dev package available for RedHat 5.5 (32bits), so I used RedHat 4.5 for my tests. I will check the rpms version of xorg on next monday. I am off this weekend. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> > OK, though I still think there should be a Better Way! This is why I posted ;) [...] > Sorry, what I meant was that when you are using an X-server (Exceed or > otherwise) to run the apps on a Linux host, but displaying on a Windows > host (which was the configuration you described initially) then, in > that case, the WIN32 code is not in play, only the X11 code, since it > is the X11 system that is rendering the display, not the WIN32 system. > > However, from your subsequent posts, I think you are also testing the > code locally on the Windows machine, and as a result we may have been > talking at crossed purposes? > Right. And Red Hat 5.5 (64bits) and Windows are the targets. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 12/16/11 09:12, Ian MacArthur wrote: > [32bit vs 64bit observations] Just to add some info to the mix: I tried a test between two linux machines: 1) fedora 3 32bit/Xorg 6.8.1 (2004)/flwm 2) centos 5.5 64bit/Xorg 7.1.1 (2006)/flwm I went on each, and ran both a local test of 'tile', and also ssh'ing to the 'other' machine and running tile through the DISPLAY. In all four cases (local on each, remote on each), no xlib errors while moving around the tiles. (I didn't resize the window, I just moved the tiles all around the screen to their extremes) So seems like this must be /very/ OS/Xserver specific. Which is not to say we shouldn't try to fix this. (It's just hard to fix if we can't replicate) I could see us possibly avoiding draws of any windows where the w or h is zero at the X interface level; probably an easy test. I don't know our X implementation very well, so I probably can't add much insight beyond that without going "down in the basement" to check for cobwebs. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 12/16/11 09:12, Ian MacArthur wrote: > [32bit vs 64bit observations] Just to add some info to the mix: I tried a test between two linux machines: 1) fedora 3 32bit/Xorg 6.8.1 (2004)/flwm 2) centos 5.5 64bit/Xorg 7.1.1 (2006)/flwm I went on each, and ran both a local test of 'tile', and also ssh'ing to the 'other' machine and running tile through the DISPLAY. In all four cases (local on each, remote on each), no xlib errors while moving around the tiles. (I didn't resize the window, I just moved the tiles all around the screen to their extremes) So seems like this must be /very/ OS/Xserver specific. Which is not to say we shouldn't try to fix this. (It's just hard to fix if we can't replicate) I could see us possibly avoiding draws of any windows where the w or h is zero at the X interface level; probably an easy test. I don't know our X implementation very well, so I probably can't add much insight beyond that without going "down in the basement" to check for cobwebs. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
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... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 15 Dec 2011, at 14:29, David FLEURY wrote: > >> Sorry, I should have said "seevral places in the flush() method without >> checking..." though mostly to call the draw() method, so if draw() is >> internally always checking that the xid is non-null it may well be >> fine...! > > Good. For now, I will keep my patch until my tests are ok for a next fltk > release. OK, though I still think there should be a Better Way! >> Ah, yes. I see - so the issue is perhaps that we should prevent Fl_Tile >> from resizing its subwindows to zero, we need to force a minimum >> dimension, that sort of thing? There's been discussion very recently as to whether a Fl_Tile ought to be allowed to resize down to zero or not at all, and I think the emerging opinion os that it should not. However, at present, it is allowed to become zero... >>> >>> On thing I see is the code under WIN32 don't seem to be reach at all >>> because draw() is not called for a 0 size window. >> >> OK - but be aware that the WIN32 code is not in play here, you are >> running the X11 code, so that's the code path that is failing for you. > > > Not sure to understand the meaning of your sentence, but I have > tested and debug my test code under Windows too. > And the Fl_Double_Window::draw() is never called (breakpoint never reach) > May be a solution would be to find why draw() is not done (w() != 0 && h() != > 0 may be for children ?) under windows and done under Linux. Sorry, what I meant was that when you are using an X-server (Exceed or otherwise) to run the apps on a Linux host, but displaying on a Windows host (which was the configuration you described initially) then, in that case, the WIN32 code is not in play, only the X11 code, since it is the X11 system that is rendering the display, not the WIN32 system. However, from your subsequent posts, I think you are also testing the code locally on the Windows machine, and as a result we may have been talking at crossed purposes? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
After further tests, I have come to more Xlib Error on using Fl_Double_Window
in a tile resize to 0.
It seems that this is not the better to design a complex Window.
At this time, I just change the Fl_Widget::visible() to remove all my errors
(adding a check against w() and h() being positive)
unsigned int visible() const {return !(flags_&INVISIBLE) && (w()>0) &&
(h()>0);}
Everything fine now.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> 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) remote display > 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. Since it's working fineon RedHat 4.5, don't think it's related to the X server used. I have done a Xlib sample that uses a XCreatePixmap at 0 size, neither RedHat 4.5 or 5.5 did not works... don't understand this. > 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. Not sure, since it's working fine with others widgets (at least a simple Fl_Window), and may be users want to made a 0 size Tile. > 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. I vote for this (I still wonder why and where WIN32 has a different behavior - draw() is not called at all for 0 size window under windows) I will keep my patch (as posted before) on my local sources until someone who know internal fltk design come up with something better. When I add some traces (into fltk itself), I see that fltk do not manage the same way the childrens under Windows and Linux. The draw is not called on Windows because children() is 0 (1 under linux ) in Fl_Group::draw_children() for the same code. Still not see where is the difference... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
>> 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. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> Sorry, I should have said "seevral places in the flush() method without > checking..." though mostly to call the draw() method, so if draw() is > internally always checking that the xid is non-null it may well be > fine...! Good. For now, I will keep my patch until my tests are ok for a next fltk release. > Ah, yes. I see - so the issue is perhaps that we should prevent Fl_Tile > from resizing its subwindows to zero, we need to force a minimum > dimension, that sort of thing? Do not know, I am not involve in fltk core developpment. So I don't know what they prefer as solution. It may me strange to remove a functionality that works for others classes because of a "bug" in a specific one. > > On thing I see is the code under WIN32 don't seem to be reach at all > > because draw() is not called for a 0 size window. > > OK - but be aware that the WIN32 code is not in play here, you are > running the X11 code, so that's the code path that is failing for you. Not sure to understand the meaning of your sentence, but I have tested and debug my test code under Windows too. And the Fl_Double_Window::draw() is never called (breakpoint never reach) May be a solution would be to find why draw() is not done (w() != 0 && h() != 0 may be for children ?) under windows and done under Linux. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> > "myi->other_xid" is subsequently used in several places > without always > > checking to see if it is NULL or not, so I worry that this > will throw > > other issues. > > > I hope not in to much places because Fl_Double_Window::resize(...) > already put other_xid to 0 (marker for deletion) > I quickly check and see nowhere unchecked used in the code Sorry, I should have said "seevral places in the flush() method without checking..." though mostly to call the draw() method, so if draw() is internally always checking that the xid is non-null it may well be fine...! > > I think it would be better if we contrived to ensure that > > the offscreen (which is used to simulate double-buffering) > > was never created with zero size, which is why I suggested > > we try setting MyWin to a nonzero value in my earlier post. > > My code was just a sample shorter than the tile one to reproduce > the same issue present on tile (when resizing to 0 a "tile" > with a double sub window) Ah, yes. I see - so the issue is perhaps that we should prevent Fl_Tile from resizing its subwindows to zero, we need to force a minimum dimension, that sort of thing? > > I assume, from the codepath, that your X-server is not reporting > > that it can support XDBE, and that is why you are seeing this > > problem. I guess that these days, most testing happens > > on servers that do claim to support XDBE so we go down > > the alternate codepath and never hit this issue? > > > May be. > > On thing I see is the code under WIN32 don't seem to be reach at all > because draw() is not called for a 0 size window. OK - but be aware that the WIN32 code is not in play here, you are running the X11 code, so that's the code path that is failing for you. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> > Hmm, I fear that will cause more problems than it solves... Probably right. But still not encounter on my tests. > > "myi->other_xid" is subsequently used in several places without always > checking to see if it is NULL or not, so I worry that this will throw > other issues. I hope not in to much places because Fl_Double_Window::resize(...) already put other_xid to 0 (marker for deletion) I quickly check and see nowhere unchecked used in the code > I think it would be better if we contrived to ensure that > the offscreen (which is used to simulate double-buffering) > was never created with zero size, which is why I suggested > we try setting MyWin to a nonzero value in my earlier post. My code was just a sample shorter than the tile one to reproduce the same issue present on tile (when resizing to 0 a "tile" with a double sub window) > Creating 0 sized windows is a Bad Thing, in general. > does the tile demo do that? It looks like ... same symptoms at least. > I'm not at all familiar with the way in which the Fl_Tile logic > works... Neither I with fltk. > I assume, from the codepath, that your X-server is not reporting > that it can support XDBE, and that is why you are seeing this > problem. I guess that these days, most testing happens > on servers that do claim to support XDBE so we go down > the alternate codepath and never hit this issue? May be. On thing I see is the code under WIN32 don't seem to be reach at all because draw() is not called for a 0 size window. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> > Might be worth trying with non-zero dimensions, just to see if that
> > makes any different here...
> >
> > e.g. try;MyWin() : T(5,5,90,90) {}
> >
>
> Works fine.
>
>
> A modified Fl_Double_Window.cxx works for me :
>
> in void Fl_Double_Window::flush(int eraseoverlay) {
>
> line 345-348 or near, I had a check on W() and H()
>
>
> #if defined(USE_X11) || defined(WIN32)
> myi->other_xid = ( w() && h() ? fl_create_offscreen(w(),
> h()) : 0 );
> clear_damage(FL_DAMAGE_ALL);
> #elif defined(__APPLE_QUARTZ__)
Hmm, I fear that will cause more problems than it solves...
"myi->other_xid" is subsequently used in several places without always
checking to see if it is NULL or not, so I worry that this will throw
other issues.
I think it would be better if we contrived to ensure that the offscreen
(which is used to simulate double-buffering) was never created with zero
size, which is why I suggested we try setting MyWin to a nonzero value
in my earlier post.
Creating 0 sized windows is a Bad Thing, in general. Does the tile demo
do that? I'm not at all familiar with the way in which the Fl_Tile logic
works...
I assume, from the codepath, that your X-server is not reporting that it
can support XDBE, and that is why you are seeing this problem.
I guess that these days, most testing happens on servers that do claim
to support XDBE so we go down the alternate codepath and never hit this
issue?
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
>
> Might be worth trying with non-zero dimensions, just to see if that
> makes any different here...
>
> e.g. try;MyWin() : T(5,5,90,90) {}
>
Works fine.
A modified Fl_Double_Window.cxx works for me :
in void Fl_Double_Window::flush(int eraseoverlay) {
line 345-348 or near, I had a check on W() and H()
#if defined(USE_X11) || defined(WIN32)
myi->other_xid = ( w() && h() ? fl_create_offscreen(w(), h()) : 0 );
clear_damage(FL_DAMAGE_ALL);
#elif defined(__APPLE_QUARTZ__)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> I have no local access.
OK - that's a pity, it will surely make diagnosis harder!
I don't have the bits to recreate your setup, so this is all going to be
guesswork and fishing.
Maybe someone clever will step up and fix it!
> The problem happens on the Fl_Double_Window (probably due to
> a buffering done in a 0 size buffer)
>
> Just a minimal sample to reproduce what seems to happen in a
> resized tile.
> launch with no arg -> Fl_Double_Window error
> launch with an arg -> Fl_Window fine
> MyWin is only here to make an entry point for ddd
>
>
> #include
> #include
>
> template
> struct MyWin : T {
> MyWin() : T(0,0,0,0) {}
Might be worth trying with non-zero dimensions, just to see if that
makes any different here...
e.g. try;MyWin() : T(5,5,90,90) {}
> void draw() {
> T::draw();
> }
> };
>
> int main( int argc, char** argv) {
> Fl_Double_Window w(30, 50, 0, 0, "Tile Test" );
and try; Fl_Double_Window w(30, 50, 100, 100, "Tile Test" );
> ( argc > 1 ? (Fl_Widget*)new MyWin
> : (Fl_Widget*)new MyWin );
>
> w.show();
> return Fl::run();
> }
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
>
> OK, that's interesting.=20
>
> (Though I guess it does not fully preclude the possibility that it is an
> X-server issue, if there's some sort of weird 32/64 thing going on or...
> Hmm...)
>
> Anyway, does it exhibit the same misbehaviour run locally on the
> machine? Is it only via Exceed that you see the fault?
>
I have no local access.
The problem happens on the Fl_Double_Window (probably due to a buffering done
in a 0 size buffer)
Just a minimal sample to reproduce what seems to happen in a resized tile.
launch with no arg -> Fl_Double_Window error
launch with an arg -> Fl_Window fine
MyWin is only here to make an entry point for ddd
#include
#include
template
struct MyWin : T {
MyWin() : T(0,0,0,0) {}
void draw() {
T::draw();
}
};
int main( int argc, char** argv) {
Fl_Double_Window w(30, 50, 0, 0, "Tile Test" );
( argc > 1 ? (Fl_Widget*)new MyWin
: (Fl_Widget*)new MyWin );
w.show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> > > Don't know, I am using a Red Hat 5.5, 64 bits, through Exceed. > > > I will check tomorrow. > > > > Exceed? Running on a Windows host? Hmm, I wonder if that's > the problem? > > > > Have you tried another server (I like Xming much better > than Exceed on = > > WIndows hosts these days, had all sorts of weird problems with = > > Exceed...) > > > > It's fine on Red Hat 4.5, 32 Bits. OK, that's interesting. (Though I guess it does not fully preclude the possibility that it is an X-server issue, if there's some sort of weird 32/64 thing going on or... Hmm...) Anyway, does it exhibit the same misbehaviour run locally on the machine? Is it only via Exceed that you see the fault? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> > Don't know, I am using a Red Hat 5.5, 64 bits, through Exceed. > > I will check tomorrow. > > Exceed? Running on a Windows host? Hmm, I wonder if that's the problem? > > Have you tried another server (I like Xming much better than Exceed on = > WIndows hosts these days, had all sorts of weird problems with = > Exceed...) > It's fine on Red Hat 4.5, 32 Bits. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 14 Dec 2011, at 21:36, David FLEURY wrote: > >> I wouldn't think font size would affect that demo though, would it? I = >> don't know. >> >> Anyway, as another ref point, testing with ubuntu 11.10, all seems fine, = >> no errors flagged. >> >> I wonder if there's something odd about your graphics driver, or = >> something? >> >> >> > > Don't know, I am using a Red Hat 5.5, 64 bits, through Exceed. > > I will check tomorrow. Exceed? Running on a Windows host? Hmm, I wonder if that's the problem? Have you tried another server (I like Xming much better than Exceed on WIndows hosts these days, had all sorts of weird problems with Exceed...) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> I wouldn't think font size would affect that demo though, would it? I = > don't know. > > Anyway, as another ref point, testing with ubuntu 11.10, all seems fine, = > no errors flagged. > > I wonder if there's something odd about your graphics driver, or = > something? > > > Don't know, I am using a Red Hat 5.5, 64 bits, through Exceed. I will check tomorrow. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 14 Dec 2011, at 19:24, David FLEURY wrote: > >> >> Do you mean the "tile_image" test program? >> >> Can't seem to replicate with 1.3.x svn current on centos 5.5 with flwm. >> > > > No tile.cxx > > I wonder if there is a link with my modified value of FL_NORMAL_SIZE from 14 > to 12 in Fl_Widget. I wouldn't think font size would affect that demo though, would it? I don't know. Anyway, as another ref point, testing with ubuntu 11.10, all seems fine, no errors flagged. I wonder if there's something odd about your graphics driver, or something? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
> > Do you mean the "tile_image" test program? > > Can't seem to replicate with 1.3.x svn current on centos 5.5 with flwm. > No tile.cxx I wonder if there is a link with my modified value of FL_NORMAL_SIZE from 14 to 12 in Fl_Widget. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Tile sample and X_CreatePixmap error
On 12/14/11 08:52, David FLEURY wrote: > Hi, > > I am testing the tile sample for the distrib, and when resizing the tile > where the subwindow is, I have these errors (under linux) : > > 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 > > Is there a way to avoid them ? Do you mean the "tile_image" test program? Can't seem to replicate with 1.3.x svn current on centos 5.5 with flwm. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Tile sample and X_CreatePixmap error
Hi, I am testing the tile sample for the distrib, and when resizing the tile where the subwindow is, I have these errors (under linux) : 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 Is there a way to avoid them ? Regards, David ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
