On 31.12.2009, at 14:32, Albrecht Schlosser wrote: > AFAICT this *should* work with FLTK 1.3. That was one reason why the > coordinate space has been extended. Although the recommendations to > do it with an own mechanism to display only the visible set of the > widgets would also be correct, maybe for performance reasons.
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. Still what Ian says holds true: if you need to manage thousands of entries, the FLTK doubly linked list may be the wrong way to handle datasets. Maybe a Scroll widget is not appropriate to begin with and you have a way to subdivide your dataset in more user-manageable pieces? As a last resort, the Fl_Scroll should probably be subclassed and the drawing be limited to visible areas. Matthias _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
