DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L1929 Version: 1.4-feature This seems to be twofold: (1) moving windows to coordinates outside the 16bit space (2) using widgets with coordinates outside the 16bit space Recent tests showed that current Windows systems seem to use 32bit coordinates internally and shouldn't have problems. X11 however, uses 16bit coordinates. Mac OS X is 32bit, AFAIK. Thus it seems that we do only have clipping problems with X11. (1) is relative to the root window. I don't know what to do with this. Maybe this is what Bill meant: we can ignore this. (2) is relative to the parent window. This can have issues, see STR #2304 <http://www.fltk.org/str.php?L2304>. I hope that I fixed a lot of these issues. I believe that the remaining issues can only be problems with large widgets inside an Fl_Scroll or with their own scrolling methods, for instance: create an Fl_Box or an Fl_Group inside an Fl_Scroll with: Fl_Box b = new Fl_Box(0,0,66000,66000); As I see it, there are these cases to distinguish: (2a) FLTK needs to decide whether a widget must be drawn and calls fl_not_clipped() with its coordinates. This happens for small widgets inside big container widgets. This is fixed. (2b) The container widget's box (or the big box's box) must be drawn with clipping, but X11 can't handle clipping. Box drawing functions consist of horizontal and vertical lines, (optionally filled) rectangles, and maybe single points. I introduced 2 clipping functions in src/fl_rect.cxx (svn r7882-7889), and they are used for these drawing functions. Hence, this is fixed now. (2c) The contents of big boxes or container widgets must be drawn. This is usually done in a widget's own draw method. This is the real problem, because we can have all drawing functions, including images, polygons (non-orthogonal lines), curves, circles, ellipses, with or w/o coordinate translations. Again it might be easy to clip the entire object, if it falls completely outside the 16bit range or the visible window part, but it may be difficult if it is partially shown. Imagine to draw a filled circle that fills the big box mentioned above. (2d) Clipping functions like fl_push_clip() must be adjusted to use only 16bit coordinates. There is no solution (yet) for 2c and 2d. Link: http://www.fltk.org/str.php?L1929 Version: 1.4-feature _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
