Matthias Melcher wrote: > Yes, we internally handle coordinates at 32 bits. Unfortunately, the > underlying OS may still be at 16 bit, which we are not prepared for. We would > have to check each and every draw command for 16 bit bounding violations and > clip the coordinates to remain within range. Since 99.9% of all drawing calls > are within screen coordinates, this would make for a huge overhead and slow > down FLTK considerably. > > Our STR should ask for clipping in the Fl_Scroll code, maybe in the box > drawing, but not for general clipping for performance reasons.
Agreed. I just made a smaller test program and added it to STR #2304 for reference. It turned out that single small widgets don't have problems (clipping works), but the big Fl_Group in the OP's test program that covers all the smaller box widgets seems to be the culprit. After reading in the code I suspect that clipping, and as you mentioned, probably the Fl_Group's box drawing code is the problem. ... I just changed the Fl_Group's box type to FL_NO_BOX, but this didn't change anything :-( Unfortunately I'm not familiar with X11 specific code, so that I'm afraid that I can't find out much more now, but maybe you could take a look and see it in a minute or so ;-P Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
