Andreas Ekstrand wrote: > We use an Fl_Scroll with a large number of buttons to accomplish a fancy > tree-view in our application. After an update to the latest FLTK 1.3, we > discovered a major fall in performance when clearing the scroll in order to > re-calculate the graph represented in the Fl_Scroll. > > We use Fl_Group::clear explicitly, I think Fl_Scroll::clear was even slower.
That's true, Fl_Scroll::clear() always removed the children one by one, but what you did looks wrong, unless you remove the scrollbar widgets before calling Fl_Group::clear and (maybe) insert them back after this. If you also delete the Fl_Scroll after Fl_Group::clear(), then, well, I'd guess that you could probably delete some widgets (the scrollbars) twice. You should check that. > The problem is that in a graph with e.g. 8000 children on one level, That's really many children. Fl_Group is not designed to hold that many children, although there's no reason why it wouldn't work. Do you have any numbers (times) how much slower the new implementation is? If yes, on what hardware and OS? That said ... > the new implementation of Fl_Group::clear which I think was introduced > January 8, 2009, is way to slow for us, removing each child separately. The > old implementation where the complete array was cleared at once was much > faster. Unfortunately the old implementation could access deleted widgets and thus cause programs to crash under certain circumstances (and depending on the memory management functions of the OS). This change was introduced together with auto-removal of widgets in their destructor and was necessary to keep internal states (group/children relations) always consistent. > Perhaps you could re-introduce the old implementation in a separate method or > with a boolean parameter to the clear method? We are looking for a quick > solution here, since we want to use the latest FLTK 1.3 with our next patch > release of our software. I'll have a look at it, but currently I can't promise a fast solution (or any solution at all). Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
