> 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.
We actually do remove the scrollbars and add them afterwards, so that would be okay. > 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? I thought I'd get an answer like that and I know this is an unusual way of using Fl_Group. Anyway, compiled in Visual Studio Debug mode, Fl_Group::clear with approximately 8000 children takes about 1500ms compared to the previous implementation which took about 870ms. Actually that difference is much larger with optimization in Release mode, although I don't have any figures from there. With Fl_Scroll::remove in Debug mode, clear took about 2400ms. > 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. I was afraid the reason would be something like that. We really have to keep our fancy tree-view and our users would certainly not be happy with a new shiny version of the product being much slower than the previous. So we would really appreciate any suggestions of workarounds or solutions. I have thought of deriving from Fl_Group ,but that introduces other problems with private members, maybe making them protected would open some doors? /Andreas _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
