Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Agreed that we should return NULL and document it; as thinking about the consequences of being permisse as windows is, I would say that if I specify anywhere in my app a (0,0) dim offscreen surface, I must bug somewhere and would like to know about it one way or another. Creating even a 1 pixel square dimension from a 0 square dim. specification does not make much sense for an offscreen_surface. Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Just some additional notes culled from the ref'd thread: It appears, based on testing by the OP (David) and by me, that the crux may be in the Fl_Double_Window flush() method. If XDBE is inhibited, then at line 338 of r9209, we have an fl_offscreen created for the double buffer, which is then assigned to other_xid: myi-other_xid = fl_create_offscreen(w(), h()); Now, it is clear that the offscreen is created without first checking that the dimensions are non-zero, and that appears to be what triggers the subsequent crash... David's workaround was to do: myi-other_xid = ( w() h() ? fl_create_offscreen(w(),h()) : 0 ); instead, i.e. only create the offscreen surface for the double buffering of the window if the window has non-zero size. Otherwise, other_xid is set to NULL. It looks like *most* other places where other_xid is used, it is checked for being NULL first, so this ought to be safe. David reports good results with this workaround in his tests, though I was initially sceptical. I'm now of the opinion that this workaround is probably good, though we need to check there are no places where other_xid is actually used without first being checked for NULL, just to be sure! Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Great -- whatever we do, sounds like fl_create_offscreen() is a possible culprit, and since it's a public (documented) function, we should probably document the w|h == 0 issue. Currently the docs don't mention a w/h of zero is bad, or if NULL is a possible return value: http://fltk.org/doc-1.3/group__fl__drawings.html#ga22259d434be43b30f74bfb3e96c5fdab So I imagine one of the following should be changed in fl_create_offscreen(): 1) Document current behavior to indicate w|h of zero causes undefined behavior, make the change you show at line 338, and make sure we handle other_xid == NULL correctly. 2) Change fl_create_offscreen()'s code to check for w|h == 0 and return NULL, document that, and warn that in versions previous to 1.3.1 there was undefined behavior for w|h == 0. And then NOT make any change to line 338, and make sure we handle other_xid == NULL correctly. 3) Allow a w|h of zero, and return a pointer to 'something' so that it doesn't crash, and document that w|h can be zero (but warn versions previous to 1.3.1 had undefined behavior) and check to make sure related offscreen functions won't crash when working with a zero sized offscreen buffer. And make no change to line 338, and make sure we handle other_xid == NULL correctly anyway (see below). fl_create_offscreen() should probably return NULL if w|h is negative and document that. (Not that that's an issue here, but it probably should) Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled+ Fl_Double_Windows resized to zero on W or H
David's workaround was to do:
myi-other_xid = ( w() h() ? fl_create_offscreen(w(),h()) : 0 );
instead, i.e. only create the offscreen surface for the double
buffering of the window if the window has non-zero size. Otherwise,
other_xid is set to NULL.
It looks like *most* other places where other_xid is used, it is
checkedfor being NULL first, so this ought to be safe.
David reports good results with this workaround in his tests,
though I was initially sceptical.
I'm now of the opinion that this workaround is probably good,
though we need to check there are no places where other_xid is
actually used without
first being checked for NULL, just to be sure!
I double check, and find an global variable initialize with this value.
Using nested double window using box can trigger X error. (PolySegment, and
PolyText).
Here my full patch :
// Checking against 0 is not enough
myi-other_xid = ( w() = 0 h() = 0 ? fl_create_offscreen(w(), h()) : 0
);
and (near line 416 of Fl_Double_Window.cxx)
#else // X:
fl_window = myi-other_xid;
draw();
fl_window = myi-xid;
#endif
is replaced by
#else // X:
if ( myi-other_xid ) {
// global init of the current X window
fl_window = myi-other_xid;
draw();
}
fl_window = myi-xid;
#endif
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current I researched what the other implementations of fl_create_offscreen() do: MAC: calls calloc() to allocate a buffer of w*h*4 in size, then calls GBitmapContextCreate(). The latter doesn't say one way or the other what happens if w|h are zero: http://developer.apple.com/library/mac/documentation/graphicsimaging/reference/CGBitmapContext/Reference/reference.html#//apple_ref/c/func/CGBitmapContextCreate I'm not sure what calloc() does if the bytes requested are 0, I don't think the man page says. I imagine the overall behavior is 'undefined' on the Mac. WINDOWS: calls CreateCompatibleBitmap() which says if w|h are zero, it acts as if a 1x1 window was requested: http://msdn.microsoft.com/en-us/library/dd183488%28v=vs.85%29.aspx X: Calls XCreatePixmap() which is explicit that w|h must not be 0. Not sure what the return value is. So we have a little of everything: X explicitly doesn't want w|h==0, Mac seems undefined Win tries to be nice by assuming you're crazy, and makes a 1x1 so that a valid buffer is returned. While I think Win's behavior is prudent, it's perhaps being too kind. I kinda think we should return NULL, document it, and make sure we check for NULL everywhere. That would be harder, but perhaps more correct. Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Yup, that sounds like the best deal... Also, why am I not getting any of these posts in my mail??? Other fltk mail seems to be arriving OK... Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Side note: This STR may also have relevance to STR 2791, where the discussion is about what happens to Fl_Tile if you resize the window to 0x0... Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current Also, why am I not getting any of these posts in my mail??? Looks like when you modify someone else's STR, you can specify your email at the Notification Update prompt, and you'll get emails. Link: http://www.fltk.org/str.php?L2797 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2797: X errors occur when XDBE disabled + Fl_Double_Windows resized to zero on W or H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2797
Version: 1.3-current
(See thread in fltk.general Tile sample and X_CreatePixmap error)
On linux (centos 5.5 for me), building fltk 1.3.x with
'configure --disable-xdbe' and running the test/tile program,
when the tiles are moved around such that the 'child window'
tile (an Fl_Double_Window itself) is sized to 0 on either W or H,
the following X windows errors occur on the console:
X_CreatePixmap: BadValue (integer parameter out of range for operation)
0x0
X_CopyArea: BadDrawable (invalid Pixmap or Window parameter) 0x11002b2
This is as far as I could get:
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():
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.
Hopefully one of our X gurus can figure this out; it's hard to trace
the problem down, due to X buffering the errors.
Link: http://www.fltk.org/str.php?L2797
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
